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SECTION  1.  INTRODUCTION  TO  VOLUME  ONE 

— Voluxae-Qjie  of  tha  ibree-vohiine  1985  DDN  Protocol  Handboole  contains  an  overview  of 
the  protocol  standardization  process  and  policies  within  the  U.S.  Department  of  Defense  • 
(DoD).  It  discusses  the  roles  of  the  Defense  Communications  Agency  (DCA)  and  the 
DDN  Program  Management  Office  (DDN  PMO)  with  respect  to  this  process.  Detailed 
specifications  for  DoD  military  standard  (MIL  STD)  computer  communication  protocols, 
which  are  required  as  part  of  the  protocol  suite  in  use  on  the  Defense  Data  Network 
(DDN),  are  included.  The  Handbook  also  outlines  the  role  of  the  DDN  PMO  in  DDN 
configuration  management,  and  provides  instructions  for  obtaining  additional  protocol 
information. 
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SECTION  2.  OVERVIEW 

The  10S5  DDN  Protocol  Handbook  Is  a  set  of  documents  which  describes  specifications 
for  MIL  STD  communication  protocob,  experimental  protocob,  and  de  facto  protocols 
in  use  on  the  DDN  and  the  Defense  Advanced  Research  Projects  Agency  (DARPA) 
internet.  (The  term  "Internet*  b  used  here  to  denote  the  overall  topology  of  the 
various  interconnected  networks  using  the  DoD  internet  protocob).  The  Handbook 
includes  the  official  DoD  MIL  STD  communication  protocob  in  use  on  the  DDN, 
ARPANET  research  protocob  currently  in  use,  and  some  of  the  protocob  currently 
undergoing  review.  Abo  included  are  background  information,  policy  information, 
implementation  guidelines,  and  instructions  on  how  to  obtain  other  protocol  information 
of  interest. 

Pleise  note  that  many  of  the  protocob  and  RFCs  that  make  up  the  various  sections  of 
thb  Handbook  have  previously  been  printed  as  separate  documents.  Consequently, 
some  of  them  have  their  own  separate  page  numbering.  So  that  the  reader  can  easily 
dbtingubh  between  the  two  sets  of  paging,  the  page  numbering  for  the  Handbook  ss  a 
whole  b  centered  below  the  footer  line,  whereas  any  page  numbering  specific  to  an 
individual  document  b  printed  above  the  footer  line. 

2.1  PurpoM  of  iho  DDN  Protocol  Handbook 

f  ,,,  «  r  ,  ,  ,  ^  j 

The  primary  purpose  of  the  DDN  Protocol  Handbook^ts  to  serve  as  a  guide  for  those 
planning  to  implement  the  Dd>  suite  of  protocob  on  various  computers  to  be  attached 
to  the  DDN,  including  the  ARPANET.  For  thb  reason  tutorial  information  and 
auxiliary  documents  art  included  in  additton  to  the  protoced  specifications  themselves. 
All  of  this  information  has  been  collected  into  one  set  d  documents  that  can  be  used  as 
a  source  book  for  Implementation  purposes.  .  ^  "  T 

Military  agencies  or  their  contractors  who  are  installing  or  planning  to  install  Local 
Area  Networks  (LANs)  or  any  other  type  of  network  which  needs  to  be  compatible  with 
the  long-haul  DDN,  wilt  w&nt  to  consult  thb  Handbook  for  information  and  guidelines. 

The  Handbook  provides  a  means  whereby  companies  and  vendors  wishing  to  do  business 
with  the  DoD  can  review  the  protocob  required  and  adapt  their  producU  or  efforts 
accordingly.  It  b  ;o  the  government's  advantage  to  he  able  to  purchase  off-the-shelf 
products  compatible  wUh  its  computer  communications  protocob,  '>s  these  products  can 
be  purchased  at  a  considerable  cost  savinp  compared  to  individual  custom 
implementations. 
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The  Handbook  is  also  widely  used  by  researchers  in  computer  science  and  network 
communications.  Many  programmers,  computer  scientists,  communications  researchers, 
and  protocol  experts  have  reviewed  and/or  implemented  these  protocols  and  have 
provided  valuable  suggestions  and  feedback  to  the  developers.  In  the  process,  they  have 
contributed  ideas  and  improvements  which  have  made  the  protocols  exceptionally 
robust  and  networthy. 

The  DoD  suite  of  protocob  preceded  many  of  the  international  computer 
communication  protocob,  and  so  architectural  and  technical  features  of  the  DoD 
protocob  have  been  incorporated  into  national  and  international  standards.  Members 
of  the  various  standards  bodies  have  found  ihe  Handbook  useful  for  reference  and 
comparison. 

3.2  ^Vhat  the  Handbook  Containa 

The  1086  version  of  the  DDN  Protocol  Handbook  updates  and  obsoletes  the  1082 
documents  entitled  IntemH  Protocol  Transition  Workbook^  Internet  Protocol 
Implementor's  Guide,  and  Internet  Mail  Protocols,  and  also  the  1083  document 
entitled,  Internet  TELNET  Protocol  and  Options* 

Since  1082,  when  those  documents  were  issued,  many  changes  have  taken  place  in  DoD 
network  communications  which  necessitate  the  Issuance  ol  thb  new  vendon  of  the 
Handbook.  Several  protocob  which  were  experimental  have  now  been  revised  and 
issued  as  military  standards  (MIL  STDs).  The  DDN  has  been  created,  and  the 
ARPANET  has  been  split  into  two  networks,  the  ARPANET  and  the  MILNET.  Both 
the  ARPANET  and  the  MILNET  are  unclaamfied  portioni  of  the  DDN;  however,  each 
network  serves  a  very  different  purpose.  The  .MILN^ET  b  an  unclassHied  operational 
milii*ry  network,  whereas  the  ARPANET  remains  an  experlmenia)  network  for  research 
and  development.  Th«e  major  changes  in  function  and  mode  of  operation  of  each 
network  are  reflected  herein  by  dividing  the  Handbook  into  three  volumes.  V^olume 
One  contains  the  DoD  operational  MIL  STD  protocob  in  use  on  the  DDN.  Volume  Two 
contains  the  currenr  official  ARPANET  research  protocob,  Vdume  Three  contains 
guidelines  and  auxiliary  Information  useful  for  implementing  either  set  of  protocob. 

it  b  important  to  note  that,  at  the  time  of  thb  printing,  the  MIL  STD  pr^cKob  have 
ementially  the  same  functionality  as  the  ARPANET  protocob.  Thb  may  change  in  the 
future.  The  MIL  STD  documents  use  a  formal  stau  machine  description  in  place  of  the 
functional  description  found  in  the  corresponding  .4RPANET  documenu.  The 
ARPANET  prolo«ds  differ  slightly  from  the  MIL  STDs  by  offering  the  implementor 
more  choices  of  Implementation  detail  than  do  the  MIL  STD  documents.  Otherwise,  the 
protocob  are  essentially  the  same. 
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Several  auxiliary  documents  are  included  in  Volume  Three,  such  as  a  list  of  assigned 
numbers,  the  ASCII  character  set  definition,  guidelines  to  implementation  details,  and 
the  like.  These  provide  additional  background  information  or  reference  data  for 
implementor'. 

Also  included  is  an  overview  of  the  administrative  process  for  the  review  and  acceptance 
of  protocols  as  military  standards  by  DoD  and  as  ARPANET  experimental  protocols  by 
DARPA. 

2.3  The  Role  of  DCA  in  Protocol  Standardization 

Under  the  Defense  Standardization  Program,  the  Defense  Communications  Agency 
(DCA)  located  in  Arlington,  VA,  has  been  designated  the  Area  Assignee  for  the 
development  of  long-haul  communications  standards.  In  this  capacity,  DCA  provides 
technical  guidance  and  coordinates  the  efforts  of  the  vai'ious  DoD  participants  in  the 
DoD  long-haul  standards  program.  Section  2.4  below  explains  in  detail  how  DCA 
carries  out  this  assignment  and  how  its  efforts  are  integrated  into  the  overall  Defense 
Standardization  and  Specification  Program  (DSSP). 
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The 

Development  of 
Communications 
Standards  in 
the  DoD 

Philip  S.  Selvaggi 

A  detailed  overview  of  procedures 
in  the  military  standards-maklng 
process 


IN  RECOGNITION  ol  the  extreme  importance  of  standardiza¬ 
tion  within  the  Federal  Government.  Congress  passed  the 
Federal  Cataloging  and  Standardization  Act  in  1952.  Immedi¬ 
ately  thereafter,  the  Department  of  Defense  (DoD)  established 
the  Defense  Standardization  Program,  with  the  purpose  of 
meeting  the  intent  of  Congress  within  the  Department  of 
Defense.  This  article  briefly  describes  the  aims,  policy 
issues,  problems,  and  philosophy  of  the  Defense  Standardiza¬ 
tion  Program,  and  then  elaborates  on  the  workings  of  the 
Program  with  respect  to  communications  standards.  The 
article  then  goes  on  to  describe  the  development  and 
methods  of  coordination  for  long-haul,  tactical,  and  common 
communications  standards.  Following  this,  brief  descriptions 
of  the  DoD  Operation  and  Maintenance  Standards  are 
provided.  The  article  then  continues  with  a  treatment  of  the 
DoD  Data  Protocol  Standards  Program.  In  order  for  data 
networks  to  be  efficient  and  reliable,  a  viable  set  of  protocol 
standards  must  be  developed  for  their  use.  This  portion  of 
the  article  describes  the  DoD  needs  in  protocol  standards, 
how  it  has  organized  to  meet  these  needs,  and  concludes 
with  a  description  of  future  DoD  efforts  in  this  area.  The 
article  then  concludes  with  a  summary  of  other  standardiza¬ 
tion  activities  which  impact  the  DoD's  standardization 
programs  and  activities. 

OepartHieiil  i!  Oifensi  Staadardlzatlen  Program 

Introduction 

Communications  systems  designed  to  serve  a  wide  variety 
of  users  very  often  must  procure  equipments  and  facilities 
from  many  different  sources.  To  design  such  systems 
effectively,  a  group  of  viable  standards  is  necessary  in  order 
to  achieve  the  OoO  objectives  of  interoperability  and  required 
performance  levels  in  a  cost-effective  manner.  Further,  when 
such  communications  systems  are  required  to  interface  with 
other  communications  systems,  standardization  is  even 
more  necessary  because  of  the  need  to  clearly  define  the 
network  interfaces,  maintain  network  functionality,  and 
preserve  expected  customer  service.  These  assertions  are 
supported  by  the  fact  that  considerable  activity  is  currently 
underway  in  national  and  international  standards  organiza¬ 
tions  for  the  purpose  of  addressing  these  issues  On  the 
international  scene,  the  CCITT  and  ISO  have  full  programs, 
supported  by  many  meetings  throughout  the  year,  which  are 
well  attended  by  representatives  of  carriers  and  equipment 
manufacturers.  Standardization  groups  on  the  national  scene 
are  also  very  active  in  many  countries  Within  the  United 
States,  for  example,  the  Electronic  Industries  Association 
(EIA)  and  the  American  National  Standards  Institute  (ANSI) 
arc  fully  as  active  as  their  international  counterparts  and 
their  proceedings  are  iust  as  well  attended 
Within  the  Federal  Government,  similar  pressures  have 
existed  for  the  development  and  maintenance  of  a  viable  set 
of  standards  for  several  decades  These  pressures  were 
responsible  for  the  Congressional  passage  of  the  Federal 
Cataloging  and  Standardization  Act  m  1952  The  obtecuve  of 
thiS  act  was  to  enable  the  Federal  (ktvernmeni  to  benefit 
from  the  many  advantages  oi  standardization  The  Depart¬ 
ment  of  Defense,  also  interested  m  benefiting  from  the 
positive  aspects  of  standardization,  quickly  established  the 
Defense  Standardization  and  Specification  Program  iDSSP) 
in  the  same  year  The  aims  and  obtectives  of  the  OSSP  are 
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basically  similar  to  those  of  all  standardization  programs, 
with  one  important  distinction,  however—the  DoD  must 
design  its  communications  systems  to  work  reliably  in  a 
military  environment.  Commercial  systems,  for  the  most 
part,  work  in  a  relatively  benign  environment.  Hence,  there  is 
no  need  for  these  latter  systems  to  operate  at  the  levels  of 
performance  or  to  provide  the  special  services  that  military 
networks  must  provide.  Because  of  this  fact,  commercial 
standards  groups  rarely  take  normal  military  requirements 
into  account  when  deliberating  over  the  content  of  a  new 
standard. 


Thi  Oifinti  Standardizilion  and  Sptciflcttion  Prognm 

The  basic  policy  regarding  OoO  standardization  is  con* 
tained  in  OoO  Oirective  4120.3.  The  Oefense  Standardization 
and  Specification  Program.  The  primary  objective  of  this 
program  is  to  ensure  that  optimal  materiel  standardization  is 
achieved  during  the  design,  development,  and  acquisition 
process.  This  objective  is  achieved  by  applying  standardiza¬ 
tion  principles,  such  as  item  commonality,  interchangeability, 
and  interface  compatibility  in  engineering  and  acquisition 
management.  The  objectives  of  the  OSSP  are  achieved  by  the 
techniques  identified  in  Table  I.  If  readers  desire  greater 
detail  on  individual  aspects  of  standardization  under  this 
program,  it  may  be  obtained  from  (1)  and  (2) 

The  DoD  standardization  program  involves  the  preparation 
and  use  of  a  broad  range  of  equipments,  parts,  materials, 
processes,  and  practices  described  in  specifications,  stan¬ 
dards.  engineering  drawings,  data  item  descriptions  (DID's). 
purchase  descriptions,  and  Commercial  Item  Descriptions 
iCID's)  A  guide  to  the  full  complement  of  these  documents, 
the  DoD  Index  of  Specifications  and  Standards  (DoOISSi 
currently  lists  more  than  45000  active  standardization 
documents  prepared  by  OoO  activities,  other  Federal 
agencies,  or  industry  groups.  To  support  DSSP  objectives, 
more  than  7000  standardization  projects  are  either  underway 
or  planned.  The  primary  objective  for  all  of  this  is  to  achieve 
a  state  of  materiel  standardization  within  the  Department  of 
Oefense  that  will  reduce  duplicative  development  and  testing 
costs  and  control  the  proliferation  of  items  m  the  inventory 


TAIICI 
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•  PnitiifMi  stirKUrdizfO  products  and  praclicts  to  satisfy  mili¬ 
tary  requtremtnts 

•  Prtparini  standarduation  documtnts  lot  tngintenng  and 
KQUiSition  usf  of  requrrtd  Standardized  products  and  practicts 

•  Pff¥ii<lia  tnt  prtparation  of  duplicative  and  overlapping 
deuriptions  of  mattneis  and  services  (for  eiampie  st^cifica- 
tions  sta^^ards  purenasi  descriptions  drawings  and  daiai 

•  Htitrifii  tnt  rtuse  of  proven  tecnnoiogy  to  sansfy  new 
equipmtni  or  system  reguirements  and  repetitive  use  of  design 
features  witnm  equipments  and  systems  imter  and  mirasystem 
standardization! 

•  btaUftMat.  as  appropriate  uniiorm  types  and  grades  classes 
and  Sizes  of  terms  and  leveis  of  performance  requirements 
«nicn  define  me  crtar;tcte:istics  of  mcietici 

•  Bevelipieg  metnods  for  systemancaiiy  reviewing  items  m  tne 
inventory  10  reduce  vitieiies  and  sizes  lo  me  mimmum  numoet 
compaiiptc  wiin  me  operating  needs  of  military  services 


The  Defense  Standardization  and  Specification  Program  is 
a  decentralized  program  with  overall  DoD  policy,  guidance, 
and  administration  centered  in  the  Office  of  the  Under 
Secretary  of  Defense  for  Research  and  Engineering  (OUSDRE). 
Advice  and  guidance  on  standardization  issues  are  provided 
to  the  OUSDRE  by  the  Defense  Materiel  Standardization  and 
Specification  Board  <DMSSB),  staffed  by  Flag  Rank /Senior 
Executive  Service  representatives  from  each  Department,  the 
Defense  Logistics  Agency  (DLA),  and  the  Office  of  the 
Secretary  of  Defense.  Overall  management  of  standardization 
policies,  procedures,  and  guidance  is  the  responsibility  of  the 
Director,  Standardization  and  Acquisition  Support  within 
OUSDRE.  Day-to-day  operations  are  delegated  to  the  Director, 
Defense  Materiel  Specifications  and  Standards  Office 
(DMSSO)  Within  each  Service  and  the  OLA.  a  Departmental 
Standardization  Office  (OepSO)  has  been  established  to 
manage  those  portions  of  the  DSSP  assigned  to  the 
respective  Department  or  Agency. 

Products  used  by  the  military  are  grouped  into  logical 
families,  such  as  space-vehicle  components,  flight  instru¬ 
ments.  and  land  mines.  These  individual  famjlies  of  products 
are  given  the  designation  of  Federal  Supply  Classes  (FSC's). 
Management  and  engineering  practices,  such  as  reliability, 
safety,  and  configuration  management,  are  identified  as 
Standardization  Areas.  For  each  FSC  and  Standardization 
Area,  a  military  organization  or  DoD  Agency,  known  as  an 
Assignee  Activity  (for  FSC's)  or  Lead  Service  Activity  (for 
Areas),  is  delegated  the  responsibility  tor  analyzing, 
planning  for.  and  ensuring  that  optimal  standardization  is 
achieved.  For  example,  the  Defense  Communications  Agency 
IS  currently  the  Area  Assignee  for  the  development  of  long- 
haul  communications  standards  for  the  DoD.  wnile  the 
Army's  Communications  Electronics  Command  fCECOM)  is 
the  Area  Assignee  for  OoD  tactical  communications 
standards 

Development  of  the  actual  specifications,  standards  and 
related  documents  is  performed  by  DoD  organizations  known 
as  Preparing  Activities  it  is  the  Preparing  Activity  s  responsi¬ 
bility  to  develop,  maintain,  and  coordinate  individual  DSSP 
documents,  and  to  ensure  that  they  meet  DoD  missio" 
requirements  Assignee  Activities/Lead  Service  Activitiff 
may  also  function  as  Standards-Prepanng  Activities  Av 
sociated  with  the  Assignee/Lead  Service  Activities  ar',' 
Preparing  Activities  are  several  other  DoD  organizations  ifc 
example,  participating  activities  custodians  review  anr 
user  activities  and  agents*  that  assist  m  the  pianmnc 
management  review,  and  preparation  of  FSC  Siandardizatio 
analyses,  plans,  and  standardization  documents 

Procedures  for  preparing  and  coordinating  these  or'cu- 
ments  are  outlined  m  OoD  4120  3-M  Defense  Standardization 
Manual  A  simplified  organization  chart  showing  the  rela¬ 
tionship  among  standardization  managemcni  offices  is 
shown  m  Fig  1  Following  i$  a  brief  description  of  me 
various  categories  of  OoD  documents  developed  under  me 
DSSP 

StancarHiiition  Oocumems 

OoO  requirements  for  repetitively  procured  products  .!•• 
described  m  specificatroos  while  services  practices 
cesses  and  data  are  described  m  standards  Somcatego-r 
of  documents  have  a  positive  impact  on  me  competiti. 
procurement  process  Their  primary  purpose  is  to  enmmu" 
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Cite  requirements  to  potential  or  selected  contractors  by 
clearly  defining  required  technical  characteristics  These 
documents  are  as  essential  to  the  acquisition  management 
process  as  the  funds  that  are  used  to  procure  the  goods  and 
services 

In  order  to  stimulate  maximum  competition  and  contractor 
creativity,  it  is  OoO  policy  to  use  performance-oriented 
specifications  and  standards,  rather  than  design  specifi¬ 
cations  wherever  possible  The  goal  is  to  indicate  what  is 
required  of  an  item  rather  than  how  to  design  develop,  and 
manufacture  the  item  In  utilizing  this  approach,  there  are 
obviously  trade-offs  to  be  made  m  certain  specific  situations 
Oiiality  logistics  and  standardization  considerations  some¬ 
times  mandate  a  comprehensive  and  complex  statement  of 
requirements  The  OoO  strives  to  maintain  a  proper  balance 
of  these  objectives  m  the  specification  process  Standardiza¬ 
tion  policies  support  the  philosophy  of  encouraging  the  use 
of  performance  specifications  but  they  also  "ecognize  that 
eicepiions  to  this  philosophy  are  often  necessary  and 
ber«eficiai 

OoO  StandifOi  and  Sp^thcauons  Oocument  Caiegonti 

Specifications  and  standards  used  by  the  OoO  are  divided 
into  three  groups —Federal  military  and  nongovernment 


Federal  specifications,  including  Commercial  Item  Oescnp- 
tions  jCIO‘5).  cover  the  very  large  number  of  civiitan-type 
products  and  services  used  by  the  Oepartment  of  Oefense 
Military  specifications  and  standards  describe  products  and 
services  that  are  inherently  military  m  nature  The  term 
nongovernment  standards'  refers  to  specifications  and 
standards  issued  by  private  sector  organizations  'not 
individual  companies)  which  describe  goods  services  and 
engineering  practices  commonly  available  to  the  general 
public 

A  basic  order  of  preference  has  been  established  for 
preparing  and  using  these  standardization  documents 
Where  a  responsive  nongovernment  standard  is  available  lor 
can  be  made  available  m  time)  it  shall  be  used  rather  than 
preparing  and  using  a  Federal  or  military  document  Where  a 
nongovernment  standard  does  not  exist  for  a  commercial 
product  or  practice  or  is  unacceptable  tor  DoDs  intended 
application,  a  CIO  should  be  prepared  and  used  When  a  more 
detailed  description  is  required  of  a  commercial  product  than 
IS  permitted  m  a  CIO  or  the  item  is  military-uniQue  a  Federal 
or  military  specification  or  standard  should  be  used 
Exceptions  to  the  mandatory  requirements  tor  these  formal 
standardization  documents  are  provided  m  Defense  Ac 
Quisition  Regulation  Section  1  Pan  t? 
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Federal  Series  Documents 

Commerciii  Item  Oescriptioni  (ClO'tj  are  simplified  Federal 
specifications  that  describ*^  the  key.  salient  physical  and/or 
functional  characteristics  of  acceptable  commercial  (or 
modified  commercial)  products.  These  documents  are  in¬ 
tended  to  be  developed  and  used  when  there  is  reasonable 
assurance  that  a  satisfactory  product  from  a  commercial 
supplier  can  be  obtained  without  the  need  for  specifying 
special  design,  testing,  quality  control,  or  packaging  and 
marking  requirements.  Where  a  minimum  of  speciai  require¬ 
ments  IS  essentia!  to  assure  the  receipt  of  an  acceptable 
commercial  (or  modified  commercial)  item,  these  may  be 
included.  As  the  need  for  greater  detail  or  unique  require¬ 
ments  increases.  Federal  specifications,  rather  than  CiD's. 
are  prepared.  CID  numbers  can  be  recognized  by  the 
constant,  nonsignificant  "A-A*”  identifier  (for  example. 
A-A-50652.  “Life  Preserver.  Vest.  Adult  or  Child"). 

Federal  Spicificatiens  are  developed  when  an  acceptable 
commercially  available  product  or  service  exists,  but 
specific  design,  performance,  interface,  or  other  essential 
characteristics  cannot  be  adequately  described  in  a  CIO. 
Federal  specifications  cover  material  used  by.  or  with  the 
potential  for  use  by.  two  or  more  Federal  agencies,  or  new 
items  of  potential  general  applications.  Unlike  CIO's.  Federal 
specifications  generally  contain  a  complete  description  of 
required  items  or  materials  and  the  provisions  for  deter¬ 
mining  compliance  with  the  requirements  Federal  specifica¬ 
tion  numbers  are  made  up  of  two  groups  of  letters,  followed 
by  numbers,  such  as  HH-l-524.  "insulation  Board.  Thermal 
(Polystyrene)  "  The  first  group  of  letters  identifies  the 
commodity  and  the  second  represents  the  first  letter  of  the 
title. 

Fidiril  Standirdt  cover  engineering  or  management  pro¬ 
cesses.  practices,  or  techniques  having  multiple  agency 
interest  These  documents  are  identified  by  the  indicator 
“  FEO-STO-"  preceding  the  document  number,  for  example. 
FEO-STO-4.  Glossary  of  Fabric  Imperfections." 


Mihtary  Senes  Documents 

Military  Speeifieatlens  are  complete  descriptions  of  products 
which  are  intrinsically  military  in  character  or  significantly 
modified  commercial  products  requiring  special  features 
design,  packaging,  or  quality  assurance  to  satisfy  military 
needs  Military  specifications  are  identified  by  the  prefix 
MIL’  or  OOO"  (for  documents  in  the  metric  system) 
followed  by  the  first  letter  of  the  first  word  m  the  title  of  the 
document,  (for  example.  MIL-W-5013.  Wheel  and  Brake 
Assemblies,  Aircraft") 

Military  Stiedirdi  are  used  to  describe  engineering  and 
management  processes  methods,  design  criteria  data 
generating  requirements  testing  techniques  and  definitions 
The  processes  defined  by  the  military  standards  are  of 
primary  concern  to  OoO  activities  These  documents  are 
prepared  either  m  book  form  indicated  by  me  prefix  MIL- 
STO-  or  OOO  STD-  'for  metric  standards)  followed  by  the 
document  numper  (for  example  MtL-STO-965  Parts  Control 
Program  ),  or  sheet  lorm  tdeniifsed  by  MS  (for  examoie 
MS-27423  Protector  Propeller  Shaft  Plastic  )  MS  sheet- 
form  stanaards  are  generally  used  to  describe  component 
parts  as  opposed  to  end  items  and  are  being  phased  out 


Ouilified  Products  Lists  (QPLs|  are  listings  of  vendor 
products  which  were  tested  to  and  met  previously  desig¬ 
nated  specification  requirements.  Such  preacquisition 
evaluation  is  authorized  only  for  products  when  there  is  a 
requirement  for  special,  expensive  tes^  equipment  not 
generally  available  to  a  potential  manufacturer,  or  when  the 
time  to  perform  testing  to  assure  acceptability  of  product 
design,  safety,  and  quality  makes  it  impractical  to  conduct 
the  tests  after  contract  award.  The  process  by  which 
products  are  evaluated  is  called  qualification.  The  fact  that  a 
product  is  listed  on  a  OPL  signifies  only  that,  at  the  time 
qualification  testing  was  performed,  the  manufacturer  could 
make  an  acceptable  product.  Normal  product  and  quality- 
assurance  testing  must  still  be  performed  in  accordance  with 
specification  and  contractual  terms.  QPL's  can  be  authorized 
for  either  Federal  or  military  specifications. 

Nandbaoki  are  reference  documents  which  bring  together 
procedural  and  technical  or  design  information  related  to 
components,  equipment  processes,  practices,  and  services. 
A  handbook  may  serve  as  a  supplement  to  specifications  or 
standards  to  provide  general  design  and  engineering  data. 
Handbooks  may  be  in  the  Federal  or  military  series 

International  Standards  are  standardization  documents  which 
reflect  agreements  on  products,  practices,  or  operations 
between  nations  or  international  associations.  It  is  desirable 
that  such  standards  be  consistent  with  existing  OoO 
standardization  documents  to  ensure  that  commitments 
under  these  agreements  will  not  adversely  affect  the  OoO 
design  and  procurement  positions  Similarly  military  stan¬ 
dards  and  specifications  will  often  implement  treaty  com¬ 
mitments.  and  should  be  consistent  with  nomreaiy  interna¬ 
tional  agreements  wherever  practical  Examples  of 
international  documents  include  North  Atlantic  Treaty 
Organization  Standardization  Agreements  (STANAGS)  Quadri¬ 
partite  Army  Standardization  Agreements  (QSTAG’s).  and  the 
Air  Standardization  Coordinating  Committee  (ASCC)  Air 
Standards 

Nongeveifiiecfit  (Vilwitaryl  Standards  are  documents  prepared 
by  nationally  recognized  industrial  and  trade  associations 
and  professional  societies  for  use  by  the  general  public 
These  documents  are  sometimes  called  voluntary  or  industry 
standards  It  is  OoO  policy  to  make  optimum  use  of  such 
standards  when  they  satisfy  military  requirements  and  to 
participate  wiih  nongovernment  organizations  in  developing 
the  standards 

Nongovernment  standard*!  are  used  by  the  OoD  m  three 
distinct  ways  adoption,  reference,  and  excerpts  The 
general'y  preferred  method  is  adoption  Adoption  i$  the 
process  by  which  OoO  expressec  format  acceptance  of 
nongovernment  documents  This  also  provides  visibility  to 
OoO  organizational  components  through  incorporation  of  the 
adopted  standards  into  tine  OoO  index  of  Specifications  anc 
Standards  (DoOtSS)  A  nongovernme.nt  document  may  also 
be  referenced  m  a  military  standardization  document  While 
m  most  instances  it  is  preferred  that  these  referenced 
documents  be  adopted,  there  are  situations  where  adoption 
IS  not  appropriate  When  only  a  paragraph  or  two  of  a 
nongovernment  document  is  to  be  used  n  may  be  mo'? 
efficient  to  directly  copy  or  excerpt  that  portion  mte  tne 
siandarttizaiion  document  after  permissior^  to  do  sc 
obtained  from  the  publishing  organization 

It  IS  clear  that  OoO  standardization  activities  must  de.i 
with  a  vast  array  of  documents  and  standards  categories  ' 
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H0BM12.  Site  Survey  and  Facility  Design  Handbook  for 
Satellite  Earth  Stations. 

Planning  Slindirdt— DCS  planning  standards  in  the 
MIL*ST0*187  series  are  expected  to  provide  uniform  guidance 
lor  the  design  of  the  evolving  and  future  DCS  These 
standards  are  based  on  DCS  system  ROT&E.  analyses,  and 
coordinated  design  decisions.  Performance  characteristics 
may  meet  the  criteria  for  communications  system  standards, 
(for  example,  proven  by  measured  performance)  or  the 
criteria  for  design  obiectives  (that  is.  best  engineering 
judgment  of  required  performance)  An  example  is  MIL-STD- 
187-320.  Transmission  Planning  Standards  lor  the  Defense 
Communications  System. 

The  following  standards  have  been  successfully  developed 
and  published  as  DoD  communications  standards 

MIL-STD-188-100- System  Technical  Standards 

MlL-STD-188-110— Equipment  Design  Standards  for  Data 
Modems 

MIL-STD-188*1 12— Subsystem  Design  and  Engineering 
Standards  tor  Cable  and  Wire 

MIL-STD- 188-1 14— Electrical  Characteristics  of  Digital 
Interface  Drcuits 

MIL-STD- 188-124— Grounding.  Bonding,  and  Shielding 

MIL-STD- 188- 140— Equipment  Design  Standards  m  Low- 
Frequency  ard  Lower-Frequency  Bands 

MlL-STD'188-161— Design  Standards  for  Facsimile 
Equipment 

Evolution  to  an  ali-digitai  network  has  raised  new 
standardization  issues  In  addition  to  the  already  published 
standards,  the  DoD  communications  standards  program  is 
addressing  the  following  maior  proitcts 

•  Caamea  Chuwei  Sttnaling— in  targe  commercial  networks, 
an  advance  m  network  efficiency  and  control  can  be 
achieved  by  common-channel  signaling  Extensive  stud¬ 
ies  have  shown  that  common-channel  signaling  can  be 
effective  m  military  networks  as  well  As  a  consequence, 
the  OCA  IS  developing  such  a  standard  for  the  OoO  long- 
haul  community  At  the  present  time  it  is  envisioned  that 
this  standard  will  be  very  similar  to  CCI7T  «7  the  most 
recent  CCITT  signaling  standard 

•  Timtiig  md  $yiiclifwiizitieti~in  an  aii-digitat  communica¬ 
tions  system  the  timing  fuf^!;on  affects  the  complexity 
of  the  entire  system  The  precision  of  the  timing  is  one 
tactor  that  determines  what  functions  can  be  supported 
by  the  system  and  the  manner  m  which  the  timing  is 
implemented  can  have  a  maior  impact  on  survivability 
The  timing  specifications  being  developed  by  CCtTT 
differ  from  those  under  development  by  the  OCA  m  the 
areas  of  survivability  robusmess  security  and  fur^c- 
itonaiify  The  DoD  i$  therefore  developing  a  timing  aiid 
synchronization  standard  vnhich  rs  more  appropriate  to 
a  mihiary  enviro.imenl 

•  Convifswii  frtai  Anataf  M  Otgiiai  TriitstatuitA-The 

burgeoning  held  of  dgMai  hansmission  'rCwires  the 
deiermiratscsn  of  performance  charactenstics  as  Atu  as 
establishment  o?  the  correlation  between  user  fequ’.re 
me.nls  artd  standards  parameters  Several  digital  trans¬ 
mission  projects  ire  in  progress  of  piftiCufar  >nteres!  ;S 
prcject  SLmC  3?^  to  develop  long  naui  system  irans 
mission  perfermarsce  standards 


•  Integrited  Strvicis  Digital  Nttwork  (iSONI— The  CCITT  is 
investigating  the  characteristics  of  this  network  with 
respect  to  future  commercial  usage  The  network  will 
have  a  large  impact  upon  military  communications  and 
standards  in  general,  Investigation  into  ISON  develop¬ 
ment  has  been  initiated  and  will  continue  for  as  long  as 
the  ISDN  remains  pertinent  to  DoO  standardization 
activities. 

Tactical  Standards  Development 

Long-haul  standards  development  has  its  counterpart  in 
the  tactical  standardization  area.  The  Joint  Tactical  Com¬ 
mand.  Control,  and  Communications  Agency  (JTC'A)  is 
currently  the  DoD  Lead  Service  organization  for  the  develop¬ 
ment  of  tactical  communications  standards  its  responsi¬ 
bilities  and  mechanics  of  operation  are  very  similar  to  those 
in  the  long-haul  arena,  it  must  also  develop  a  yearly  Program 
Plan  which  governs  its'  activities  over  a  five-year  span:  the 
categories  of  standards  treated  are  also  very  similar  to  those 
in  the  long-haul  area.  Needless  to  say.  there  is  very  close 
coordination  between  the  long-haul  and  tactical  standardiza¬ 
tion  areas  in  connection  witn  the  development  ot  their 
respective  Program  Plans 

Common  Standards  Program 

Some  years  back,  under  direction  from  the  Joint  Chiefs  of 
Staff  UCS).  DCA  and  ECOM  (JTC^A’s  early  predecessor  as  the 
tactical  standardization  area  assignee)  signed  a 
Memorandum  of  Understanding  (MOU)  committing  both 
organizations  to  cooperate  in  developing  common  standards 
for  the  long-haul  and  tactical  communities  This  MOU  called 
for  the  establishment  of  a  Joint  Steering  Committee  (JSC)  to 
organize  and  manage  this  effort  The  members  of  this 
committee  are  representatives  of  services  and  OoO  agencies 
representing  both  tactical  and  long-haul  interests  Then 
objective  is  to  emphasize  common  standards  development 
and  reduce  the  number  of  standards  that  are  unique  to  DoD 
communications  Such  an  approach  yields  many  advantages 
to  OoO.  not  the  least  of  which  i$  that  it  fosters  mtei- 
operability  between  long-haul  and  tactical  communication 
systems  The  level  of  standards  expertise  and  txpenencr 
present  m  this  committee  together  with  tne  resultant  cross 
fertilization  of  ideas  have  made  the  committee  a  v*»'/ 
powerful  forum  for  all  OoO  commrnications  standards  issues 
whicn  include  technical,  admimstretive  and  policy  matte: s 
The  committee  is  very  effective  m  enabling  OoO  to  discharge 
Its  responsibilities  m  the  long-naui  arsd  lacncu!  communicji 
tions  areas  ot  the  DSSP  The  JSC  p<ovides  (he  basis  fo* 
managing  communications  standards  development  m  ih^ 
DoO  It  establishes  the  need  for  new  proiecis  and  assigr^s  a.nz 
manages  DoO  standardization  resources  The  MOU  and  jCS 
action  incidentally  were  the  outgrowth  of  a  gene*ji 
realiZJtiorr  that  there  was  no  real  reason  for  most  oifte»ence> 
between  the  reouiremems  m  the  two  standardization  a-ea^ 
Other  diffrrentes  were  quiCkty  disappearing  as  a  result  y 
the  devetopmenf  of  digital  communications  and  mic-oc^C-  ' 
tecnnoiogv  S<r^ce  its  mception  the  common  s!arca-£:> 
ptogram  has  xignificarttiy  co.ntnbuted  to  fnie‘ope?aD»!»!. 
between  long-nayi  jnd  tactical  commumcitsons  s>ste‘*> 
and  today  the  buii<  ot  communicat>or>s  standards  wou  t*  “ 
Department  of  Defense  resides  tne  common  sianda-.’t. 
caiegory  The  development  ot  a  common  stanai'ds  P'og'.im 
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IS  therefore  necessary  to  maintain  a  listing  of  alt  such 
documents  for  reference  purposes,  the  DoD  Index  of  Specifi¬ 
cations  and  Standards  or  OoDISS.  The  OoDiSS  is  a  reference 
publication  that  lists  alt  military  and  Federal  specifications, 
standards,  handbooks.  QPL's,  commercial  item  descriptions, 
adopted  nongovernment  standards,  international  documents, 
and  related  publications  Printed  editions  are  provided  in 
alphabetic,  numeric,  and  Federal  Supply  Classification 
listings.  They  are  published  annually  with  bimonthly  cumula¬ 
tive  supplements.  Weekly  bulletins  called  OoOISS  Notices 
contain  advanced  information  about  selected  new  and 
revised  DoOlSS  listed  documents 

CoinmuRlcttiont  Stindirdt  OiviiopmMt 

Long^Haul  Standards  Development 

Under  the  Defense  Standardization  Program,  the  Defense 
Co.nmunications  Agency  (DCA)  located  in  Arlington.  VA.  has 
been  designated  the  Area  Assignee  for  the  development  of 
long-haul  communications  standards.  In  this  capacity,  the 
DCA  provides  technical  guidance  to  and  coordinates  the 
efforts  of  the  various  DoD  participants  m  the  DoO  long-haul 
standards  program.  The  DCA  was  created  in  1962  for  the 
purpose  of  integrating  DoD  long-haul  communications  re¬ 
quirements.  and  satisfying  these  requirements  by  the  estab¬ 
lishment  of  common-user  communications  systems  To 
enable  it  to  meet  this  objective,  the  DCA  has  been  given  the 
authority  to  design,  build,  and  manage  the  required  systems 
As  a  consequence  for  the  past  20  vears  or  so.  the  OCA  has 
been  involved  with  the  engineering  planning  needed  to 
establish  new  OoO  systems  and  to  update  these  systems  m 
accordance  with  the  trend  of  OoO  requirements  Its  responsi¬ 
bilities  make  the  OCA  the  ideal  body  to  direct  a  standards 
program,  since  standards  are  intimately  tied  m  with 
architectural  concepts,  interface  design,  system  per¬ 
formance.  and  equipment  and  facility  design  The  stan¬ 
dardization  process,  however  is  a  broad  OoO  program 
involving  all  DoO  elements;  to  completely  meet  its 
standardization  responsibilities,  the  OCA  must  make  ex¬ 
tensive  use  of  resources  provided  by  the  Military  Depart¬ 
ments  and  DoO  agencies,  strategically  supplementing  this 
support  with  actual  m-house  engineering  resources  available 
at  OCA  This  arrangement  has  proven  to  be  extremely 
effective  for  the  DoO 

The  primary  management  tool  for  the  development  of  'ong- 
haul  standards  is  the  Program  Plan  This  plan  which  is 
issued  yearly  covers  a  span  of  five  years  it  contains  the 
status  and  responsibilities  for  ongoing  protects  a  summary 
of  problems  facing  the  OoO  standards  community  and  a 
technical  analysis  of  future  communications  planning  to 
identify  standardization  needs  The  development  of  this  plan 
as  does  me  development  of  standards  m  this  area  involves 
considerable  effort  Both  responsibilities  call  for  intensive 
collaborative  efforts  between  the  DCA  and  me  Military 
Departments  and  Defense  Agencies 

Standardization  efforts  for  the  Standards  for  Long-Haul 
Communications  iSlHCi  area  assignment  are  cunentiv 
planned  and  managed  with  a  view  towards  promuigatiurr  or 
Such  standards  for  me  DCS  as  described  m  me  following 
categories 

Design  Engmevinf  SUndargs- These  standards 
establisn  overall  minimum  system  and  subscriber  to- 
subscriber  measures  of  performance  for  eiampte  me 


probability  of  achieving  given  delay  and/or  quality  m 
information  transfer  Within  circuit  and  network  models, 
total  system  and  subscriber-to-subscriber  performance 
parameters  are  apportioned,  included  are  reference  circuits, 
system  diagrams,  interrelationships  and  interconnectivity  of 
component  subsystems,  and  performance  goals  The  fatter 
includes  system  efficiency,  communications  quality,  delay, 
flexibility,  availability,  reliability,  survivability  and  security 
goals.  The  system  design  and  engineering  standards  provide 
the  basis  for  the  interconnection  of  subsystems  into  a 
system,  as  well  as  the  design  of  individual  subsystems,  and 
may  address  characteristics  pertaining  to  the  interconnec¬ 
tion  of  DCS  subsystems  and  interoperability  of  the  DCS  with 
other  DoD  and  no.n-DoD  communications  systems  An 
example  is  MIL-STO-186-100.  Common  Long-Haul  and 
Tactical  Communication  System  Technical  Standards 
Another  is  MIL-STD- 188-323.  which  provides  criteria  and 
guidance  for  the  design  of  DoD  long-haul  transmission 
systems. 

Subtytltm  Ouign  and  InginHring  Standards— These  stan¬ 
dards  provide  electrical  performance,  message  integrity, 
grade  of  service,  interface  standards,  and  other  parameters 
of  subsystems  such  as  switching  and  transmission  sub¬ 
systems  Where  applicable,  the  parameters  for  these 
standards  are  based  on  performance  parameters  derived 
frpm  the  system  design  and  engineering  standards  An 
example  is  MIL-STD-310A.  Subsystem  Design  and  Engineer¬ 
ing  Standards  for  Technical  Control  Facilities 

Equipment  Technical  Design  Standards— These  standards 
provide  the  minimum  electrical  performance,  such  as  the 
dynamic  range  ot  operation  mput/ouipui  parameters,  and 
intertace  characteristics  required  of  the  equipment  Most  of 
these  standards  are  based  on  the  requirements  of  the 
appropriate  subsystem  design  and  engineering  standards 
An  example  is  MIL‘STD-188-110.  Equipment  Technical  Design 
Standards  Common  Long-Haul /Tactical  Data  Modems 

Intertace  Standards- These  standards  specify  the  required 
quantitative  values  tor  electrical  parameters  and  tor  opera¬ 
tional  procedures  which  affKt  the  transparency  of  the 
interface  between  separate  subsystems  or  systems  The  term 
transparency  means  that 

•  From  the  user  s  standpoint  there  should  be  no  addi¬ 
tional  ettort  or  concern  when  his  communications  are 
traversing  separate  systems  ideally  the  user  s  operat¬ 
ing  procedures  snould  require  no  change  nor  should 
operations  be  degraded  m  any  manner 

•  Black-box  interfaces  should  be  minimized  or  elimi¬ 
nated  by  careful  analysis  ot  the  combined  systems  being 
traversed 

•  intertace  standards  provide  the  necessary  technical 
parameters  for  the  mierconneciion  of  me  .anous 
subsystems  of  the  DCS  and  are  included  as  an  integral 
part  of  Subsystem  and  equipment  iechnic.il  design 
star^darfls  m  accordance  with  the  system  des.gn 
engineering  standards  An  example  is  Mil  STO  '88  ”-i 
Electrical  Characteristics  of  Digital  Inte'fatr  C<‘.-its 

Ninth— ht -Handbooks  prov.de  gu  flaf'ce  pertair  ng  •; 
instailaiion  of  communications  equiprheni  riciittses  Kj-f 
books  cover  such  areas  as  theory  equipment  tavc-'  s.g-a: 
and  power  *:i&te  funs  environmental  rontroi 
transmission  lines  and  antennas  An  etampie  is  Vit 
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represents  a  highly  significant  development  in  DoO  com¬ 
munications  standards  and  has  contributed  greatly  to  the 
furtherance  of  OoD  standardization  objectives. 

Operational  and  Maintenance  Standards 

Communications  standards  for  the  DCS  are  usually 
thought  of  as  being  confined  to  the  MIL*STD-t8S-series 
developed  under  the  DSSP.  However,  another  important  area 
of  communications,  standards,  vital  to  the  day-to-day 
operation  of  the  DCS.  is  the  Operations  and  Maintenance 
(O&M)  standards  category.  These  standards  are  also 
developed  by  DCA.  in  collaboration  with  the  Military 
Departments,  and  published  in  DCA  Circular  300-17^-9.  They 
provide  criteria  by  which  both  the  Military  Oepartr;ents  and 
the  DCA  can  gauge  how  welt  transmission  links  and 
associated  systems  perform  and  how  well  they  are  being 
maintained.  These  criteria  take  into  account  degradation  due 
to  aging  and  adverse  local  environmental  conditions.  O&M 
Standards  also  include  DCS  Transmission  Technical 
Schedules,  which  contain  itemized  listings  of  all  common 
services  provided  by  the  DCS  and  the  circuit  parameters 
required  to  meet  end-to-end  performance  requirements.  The 
standard  also  contains  a  list  of  carrier  offerings  which  most 
closely  correspond  to  the  defined  DCS  services.  This  listing 
at  present  pertains  only  to  the  CONUS.  However,  similar 
listings  are  currently  under  preparation  for  Europe  and  the 
Pacific.  The  Schedules  also  provide  a  common  language  for 
circuit  ordering  allocation,  activation,  operation,  and 
maintenance 

This  circular  is  prepared  and  updated  by  an  O&M 
Standards  Technical  Working  Group  comprised  of  representa¬ 
tives  from  field  and  operating  units  The  practice  of  soliciting 
direct  input  from  field  and  operating  units  started  seveiai 
years  ago  and  resulted  m  substantial  improvements  to  the 
document  This  was  a  healthy  sign,  denoting  existing  user 
interest  and  a  serious  need  for  updating  the  document  in 
order  to  make  it  more  responsive  to  actual  operating 
conditions  The  result  of  this  progressive  step  was  that 
yearly  meetings  have  since  bHn  held  with  similar  results, 
and  such  meetings  are  planned  annually  from  now  on  This 
Working  Group  is  organized  and  chaired  by  a  representative 
from  the  OCA  Standards  Office 

An  example  of  this  group  s  effectiveness  arose  several 
years  ago  The  issue  addressed  by  the  group  had  to  do  with 
problems  in  the  fittd  when  operating  modems  at  4800  and 
9600  b/s  over  conditioned  circuits  mnting  existing  DCS 
circuit  standards  By  comparing  experiences,  the  working 
group  members  came  to  the  realization  that  perhaps  current 
OoO  transmission  schedules  were  too  stringent  To  overcome 
this  problem  several  new  transmission  schedules --based 
upon  reducing  conditioning  requirements— were  developed 
for  the  DCS  It  appeared  likely  that  improved  performance 
could  be  achieved  over  DCS  data  circuits  by  use  of  these  new 
schedules  There  was.  however  insufficient  data  available 
from  either  commercial  or  government -owned  networks 
which  would  correlate  the  effects  of  reduced  circuit  condi¬ 
tioning  with  modem  performance  at  rates  greater  than 
2400  b/s  For  this  reason  arrangements  were  made  with  the 
All  Forces  Rome  Air  Development  Center  (RADCi  to  test 
appropriate  modems  over  lines  simulating  the  new  transmis¬ 
sion  schedule  Test  reports  were  favorable  and  the  new 
schedules  were  validated  Considerable  cost  savings  wilt  be 


effected  over  the  years  by  reducing  the  need  for  line- 
conditionirtg  equipment.  These  savings  would  be  derived 
from  equipment,  installation,  and  maintenance  costs  and  are 
directly  attributable  to  the  development  of  0-M  standards 
and  strengthening  the  feedback  from  field  users  to  f's 
standards  development  process. 

Oiti  PrtiMif  Stindartft 

Protocols  are  the  rules  and  conventions  whereby  digital 
communications  are  effected  between  subscribers,  between 
subscribers  and  networks,  and  between  networks.  At 
present,  this  category  of  standards  represents  an  area  of 
extreme  interest  and  activity  on  the  part  of  the  DoD.  The  DoD 
has  always  had  an  urgent  requirement  for  data  communica¬ 
tions.  and  in  recent  years  the  critical  needs  of  command  and 
control  have  magnified  this  requirement  many  times  over. 
Emerging  computer  technology,  with  a  wide  range  of  appli¬ 
cability.  has  catered  admirably  to  military  command  and 
control  needs  and  has  pruvided  a  sound  basis  for  building 
computer  networks.  Although  these  networks  are  well  suited 
for  meeting  military  needs,  the  business  and  commercial 
worlds  have  found  similar  uses  for  them:  their  growth  has 
been  rapid  m  the  private  sector  as  well. 

It  is  clear  to  all.  mtlitary  and  nonmilitary  users  alike,  that 
the  successful  operation  of  these  new  data  networks 
depends  upon  the  development  of  an  effective  set  of  protocol 
standards.  The  DoD  recognized  this  fact  very  early  in  the 
game,  and  for  some  15  years  has  been  engaged  m  a  very 
extensive  program  of  network  experimentation  concerned 
with  ihe  development  of  data  protocol  standards.  This 
research  and  development  effort  established  the  basis  for 
development  of  the  OoO  data  protocol  standards  program 
today,  and  indeed  has  providid  a  stimulus  as  well  tor  the 
development  of  commerciat  standards  m  this  area.  An 
overriding  consideration  in  tht  evolution  of  tht  OoD  program 
IS  that  It  IS  constrained  by  the  need  to  mnt  unique  military 
requirements  as  well  as  by  the  OoO  policy  to  use  civil 
standards  where  appropriate  in  fKt.  all  constraints  relating 
to  the  OoO  role  in  developing  communications  standards 
hold  true  for  its  rote  m  developing  data  protocol  standards 

The  OoD's  Protocol  Standardnauon  Program 

With  OoO  s  expanding  data  reouuements  and  technciogy  s 
growing  capaOHity  to  satisfy  these  demands  the  DoO.  m  me 
mid  Seventies  along  with  everyone  else,  found  itself  m  the 
midst  of  the  data  revolution  Requirements  technology 
programs,  and  systems  wen  burgeoning  everywhere  but 
there  were  no  standards  :o  guide  the  design  and  integration 
of  these  data  systems  u  to  facilitate  the  transfer  of 
information  between  data  lerrT'.inats  and  host  computers  or 
between  computer  networks  In  recognition  ot  this  situation 
the  OoO  m  December  1978  created  the  DoO  Host-io-Host 
Protocol  Standardization  Program  and  directed  mat  the  DCa 
become  the  Executive  Agent  ’or  this  program  it  should  be 
poinied  out  that  as  described  xiriier  the  DSSP  nao  been  m 
existence  and  funcnonmg  welt  for  many  years  The  Protocol 
Standardization  Program  covid  theK*tore  nave  been  rou¬ 
tinely  included  m  the  DSSP  The  Executive  Agent  -oute  was 
chosen  however  because  the  OoO  conside»fd  the  cevefop 
meni  ot  protocol  standards  to  be  extremefy  impoftant  and  it 
wished  to  piKf  strong  emphasis  on  this  fact  The  duties  of 
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FtMCTHM  OF  T«  CUCOriN  ASfOT  FM  PlITtCIl  tTMNMmiTIM 


t)  Provide  a  Forum  for  discussion  with  MILOFPS/Agencies  on 
requirements  tor  Standards 


2)  Prepare  new  proposals  tor  Standards,  or  enhancements  and 

modifications 

3)  Document  Standards  and  their  specifications 

4)  Provide  configuration  control  of  Standards  and  their  specifi¬ 

cations 

5)  Evaluate,  approve,  or  disapprove  proposed  Standards  and 

specifications 

61  Evaluate,  approve,  or  disapprove  requests  tor  waivers 
7)  Test  proposed  Standards  and  spe«.iticaiions 
81  Coordinate  DoO  ROT&E  efforts 
9l  Provide  a  forum  tor  the  eichange  of  lechmcai  information 

10)  Monitor  Federal,  national,  and  international  Standards 

devetopment 

11)  Ensure  that  OoO  Standards  developmeni  considers  Federal. 

national,  and  international  Standards 

12)  Justify  OoO  requirements  for  waivers  from  Federal  mtormaiion 

Prxessing  Standards  <FIPS)  PUBS 

13)  Prepare  OoO  instructions  stating  OoO  policy  on  protxol 

standardization 

14)  Coordinate  IN  OoO  Proixol  Standard  Program  with  cor¬ 

responding  NATO  xliviiies 


the  OCA  in  conjunction  with  this  assignment  are  shown  in 
Table  II 

Id 

OCA'S  Orgamzatm  for  the  Executive  Agent  Role 

The  list  shown  in  Table  II  represents  a  broad  gamut  of 
functions  involving  managerial,  technical,  administrative, 
and  policy  responsibilities.  To  handle  this  full  scope  ol 
responsibilities  the  OCA  formed  three  groups,  the  Protocol 
Standards  Steering  Group  (PSS6),  the  Protocols  Standards 
Technical  Panel  (PSTP).  and  the  Configuration  Control  Office 
The  responsibility  for  implementing  protocol  configuration 
control  lies  in  the  Defense  Communication  System  Di¬ 
rectorate  01  the  OCA.  The  first  two  groups  have  representa¬ 
tion  from  services  and  OoO  agencies,  but  are  chaired  by 
members  of  OCA.  Within  OCA.  the  primary  responsibility  for 
each  group  rests  with  the  OCA  organization  most  concerned 
with  the  individual  group's  function.  The  relationship 
between  these  groups  and  the  Agency  is  shown  in  Fig  2. 

The  Oirector.  OCA.  is  actually  the  Executive  Agent  for  the 
OoO  Protocol  Standardization  Program.  The  Chairman  of  the 
PSSG  acts  for  the  Oirector  with  regard  to  OCA's  responsi¬ 
bilities  in  this  area.  He  recommends  standard  policy 
decisions  to  the  Oirector.  and  servn  as  a  focal  point  on  his 
behalf  lor  overseeing  the  performance  of  ExKutive  Agent 
functions  The  PSSG  itself  represents  the  Military  Depart¬ 
ments  and  DoO  agencies  and  serves  in  an  advisory  capacity 
to  the  OCA 
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1)  ProvMit  a  forum  for  discussion  witti  MiLO€P$/Agencies  on 

requirimtnts  for  Standards 

2)  Coordinate  OoO  ROTIE  efforts 

3t  Monitor  Federal,  national,  and  international  Standards 

4)  Ensure  that  DoO  Standards  devtlopment  considers  Federal. 

national,  and  international  Standards 

5)  Justify  OoO  reiiuirements  for  waivers  from  FIPS  PUBS 

S)  Prepare  OoOf’s  stating  OoO  policy  on  Protocol  Siandarditation 


The  responsibility  for  supporting  the  PSSG  lies  in  the 
Planning  and  System  Integration  Directorate  (PSD  of  OCA 
This  Directorate  is  responsible  for  overall  DCA  planning  as 
well  as  integration  of  the  various  OCA  and  OoO  communica¬ 
tions  programs  The  major  functions  of  the  PSSG  are 
summarized  in  Table  III 

The  PSSG  receives  technical  support  from  the  Protocol 
Standards  Technical  Panel  (PSTP).  The  PSTP  reports  to  the 
PSSG  and  is  rnponsible  for  fulfilling  the  technical  functions 
of  the  Executive  Agent.  Liaison  with  the  PSSG  is  maintained 
by  having  as  the  PSTP  Chairman  a  member  of  the  PSSG  A 
summary  of  its  responsibilitin  is  shown  in  Table  IV 
The  responsibility  for  directing  the  efforts  of  the  PSTP  lies 
m  the  Defense  Communications  EngmMnng  Center  (DCEC) 
which,  for  some  time  now.  has  bnn  responsible  for  the 
design  of  the  DCS  These  responsibilities  also  include  design 
and  planning  for  the  data  networks  m  the  DCS  as  well  For 
the  past  several  years,  the  Center  has  been  heavily  involved 
in  protocol  standards  work  and  has  made  significant 
contributions  to  the  OoO  protocol  standardization  effort 
The  third  area  of  responsibility  is  Protocol  Configuration 
Control  The  purpose  of  this  function  is  to  ensure  interopera¬ 
bility  between  protocol  standards  developed  by  different 
sources,  validate  vendor  implementations  of  protocol  stan¬ 
dards.  control  deviations  and  waivers  from  established 
standards,  and  maintain  a  document  data  base  ot  approved 
standards  This  function  is  now  discharged  by  a  newly 
created  Configuration  Control  Office  in  the  Defense  Com¬ 
munications  Systems  Dnectoratt  This  office  will  conduct 
those  activities  necessary  for  establishing  configuration 
control  of  OoO  protocol  standards  and  serves  as  a  tocal 
point  tor  identifying  and  evaluating  requirements  for  new 
protocol  standards  or  capabilities  This  activity  maintains 
coordination  with  the  PSSG  by  appointing  a  representative  to 
this  latter  group  Table  V  summarizes  the  duties  involved  m 
the  protocol  standards  configuration  control  function 

Cumfit  OoO  firo/ocof  Sl»n<s»fOuitton  Pfons 

By  the  end  of  t9^  when  the  OoO  appointee  the  DCA 
Executive  Agent  for  the  development  of  protocol  standards 

Tam  IV 

Nmcn  tiMoim  Ticmxck  Pmii  hmfm 


tt  PrtOiit  new  oiooesan  tnnanetnwnit  and  mootficaiion)  tof 
h>oiocoi  Stanoaius 

?i  Test  oroooiee  Protocol  $tanoa«es  and  sptCitKatmm 
Ji  Pro»»de  a  to»w«  H>r  tfit  ttcnangt  of  iKnA<ai  tf»io»mat«on 


t)  Document  Standards  and  their  specifications 

2)  Providt  configuration  control  ot  Standards  and  their  specifr- 

cations 

3)  Evaluate,  approve,  or  disapprove  proposed  Standards  and 

specif  icatitiis 

4)  Evaluate,  approve,  or  disapprove  requests  for  waivers 


considerable  work  had  been  done  in  developing  a  Transmis¬ 
sion  Control  Protocol  (TCP)  and  an  internet  Protocol  (IP)  by 
OCA  in  conjunction  with  its  design  efforts  on  data-com- 
munications  networks.  The  TCP  corresponds  to  the  transport 
layer  of  the  ISO  model,  which  at  its  inception  had  provision 
for  an  IP.  TCP  is  an  end-to-end  protocol  providing  reliable 
data  stream  communications  with  the  guaranteed  mtegniy 
IP  IS  a  protocol  tor  providing  data  transmission  from  host-to* 
host  over  a  set  of  interconnected  diverse  networks  At  the 
time  these  standards  were  developed,  there  were  no  formal 
standards  in  these  two  areas,  civil  or  otherwise.  The  OoD. 
however,  pressured  by  urgent  requirements  and  the  demands 
of  program  implementation,  strongly  felt  the  need  tor  such 
standards  in  its  data  communications  programs  Therefore,  m 
December  1978  the  DoO  decreed  that  these  two  standards 
the  TCP  and  IP.  would  become  official  OoD  protocol 
standards  The  reason  for  this  action  was  that  both  protocols 
had  been  devised  to  mut  the  essential  military  requirements 
of  security,  survivability,  and  reliability  These  factors  were 
considered  to  be  sufficiently  pressing  to  justify  the  adoption 
of  the  TCP  and  IP  ir.  the  absence  ut  comparable  commercial 
standards  Pecentiy.  some  revisions  were  made  m  these 
standards,  but  their  mam  sut'^  anet  has  not  changed  since 
their  adoption  m  1971  The  functions  ot  this  TCP  are  shown  m 
Table  Vt 

As  stated  above  an  internet  protocol  was  not  provided  tor 
m  the  ISO  model  However,  m  the  OoD  the  internetting  of  data 
networks  is  an  extremely  important  requirement  because  of 
the  targe  number  of  such  networks  which  serve  me  OoO 
Therefore  early  DoO  data-communications  planning  efforts 
were  geared  to  solving  the  internet  problem  in  1974  tor 
example,  the  OoD  miiiattd  a  special  study  primarily  tor  me 
purpose  ot  studying  OoO  data  internet  requirements  The 
conclusions  of  this  study  played  a  major  role  m  determining 
the  course  ot  OoO  data  communications  activities  over  me 
last  eight  years  To  illustrate  the  need  tor  mis  study 


TiHf  VI 
fwtmom  TtP 


1)  hofiltvt  ecXiyiwifOgmcnt  anq  rtiraftsmtttien 
^  ChteX  Him  on  oita  tegmtntt 
Sequencing 
4i  Flow  control 
Si  MuHiplfiirtq  ot  mkj 

•  Allow*  meny  gvocesm  witni.n  t  to  fC? 

Simuf’ane^V 

ft  Ane  Kttvf  torwwctsoni 

•  Mamiaini  *U!u4  -nfoimaiion  tati  sjij  uream 

h  xne  serwrity 


51 


JdtitKtfv  ItMin— V(»l  JJ.  \u  I 
IKM-'  ('(ttniittinit  rtiHmik  tMiSwentr 


1-15 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


TAIUVH 
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Gtfltral-purpOM  Wtwdrks  (For  tiampit.  ARP AN£T) 

PKktt  rad>c  (Sn.  FT  BRAGG) 

Facktt  tattilitt  (SATNET.  WBNED 
Military  Nttwofkt  (WIN.  OoOlSS.  DON) 

Local  Arta  Nttwerks  (ETHERNET.  RING.  MIT^BUS) 

PuMiC  Data  Nttworks  (X  21 IPSS.  0ATEX>P) 

Eiptrimenial  Nttworks  (RSRE  Piloi  Packtt*SwitcD  Nttwork) 


Table  VII  lists  a  few  of  the  most  important  data  networks 
that  a  OoO  common-data-user  system  must  interoperate 
with. 

This  list  IS  formidable  enough  but  not  nearly  complete.  The 
OoO  keeps  track  of  the  nttworks  it  may  have  to  deal  with 
and  a  recent  estimate  indicates  that  the  numbers  of  such 
nets  IS  considerably  in  excess  of  those  shown  in  Table  Vii 
The  area  of  local  Area  Nttworks.  for  example,  hat  a  vry 
great  potential  for  introducing  a  wide  variety  of  specialised 
nttworks  into  the  picture 

Table  Vlll  summarises  the  functions  of  the  Internet 
Protocol  Standard  Because  the  ISC  model  did  not  provide  for 
an  internet  protocol,  it  is  not  clear  to  which  layer  tN  IP 
belongs  There  is  strong  feeling  that  it  belongs  somewhere 
between  the  3rd  and  4th  layers,  and  recently  ISO  has  piKtd 
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1)  AMrnsing 

•  PreviOH  the  network  number 

•  ProviOH  the  heii  address 

2)  Protocol  number 

•  Keys  the  neil  hipher-leyet  protocol  to  be  used  to  inters 

internet  datagram  data 

3)  FragmemaiiOA  and  reassempiY 

•  Allows  datagrams  to  be  pasted  through  networks  mth  sman 

packnt  Site  utm 

•  Attowt  reassembty  ot  iragments  at  ^imation  host 
4i  Type  ot  servtce 

•  Provides  a  network  tnotpendem  indication  ot  desired  OuaMty  ot 

service 

•  Aitows  user  to  specrty 

Precedence 
Stream  or  daiagr^n 
Nehabitity 
Speed 

Speed  over  reHabmty 
5l  Tune  to  live 

•  Specifies  maiimum  time  mat  a  oatagran  is  aitewed  to  ti-st  «n 

me  inrernet  environment 
Si  ChKk  Sum 

•  Provides  a  cNcs  turn  toi  nearkn  protection 
Options 

•  Source  routing 

•  Record  route 

•  Error  ff^t 

|i  does  not  provide 

•  f  io»  control 

•  Data  error  control 

•  %Q  Kknoerteogmentt  of  #  datagrams 


its  function  in  layer  3.  the  network  layer  of  the  OSl  model  At 
present,  the  OoO  Internet  Protocol  has  been  proposed  to  boin 
ANSI  and  the  ISO  through  the  auspices  of  the  National 
Bureau  of  Standards  (N6S)  The  last  reports  are  that  it  is 
being  welt  received  in  both  groups.  The  need  for  a  general 
internet  protocol  is  well  recogniaed  and  such  a  protocol  will 
be  developed  before  long  In  addition  to  the  TCP  and  IP.  the 
OoO  has  plans  for  tne  development  ot  a  number  of  other 
protocol  standards,  which  are  shown  in  Table  IX  together 
with  expected  completion  dates  The  development  of  these 
standards  will  be  done  mainly  through  contractual  support 
and  coordination  with  the  N8S  protocol  standards  program 
The  OoO  has  developed  a  working  agreement  for  the 
development  of  protocol  standards  with  the  NBS  through 
which  It  Will  provide  technical  assistance  to  the  OoO  and  also 
represent  the  OoO's  interests  m  the  appropriate  civil 
standards  fora. 


Nttionti  Actdttny  ot  Icrtncf  Study 

Since  the  adoption  of  TCP  and  IP  as  formal  standards  by 
the  OoO.  there  has  been  considerable  activity  m  the 
commercial  standards  arena  with  regard  to  the  development 
ot  protocol  standards  As  a  result  of  this  activity,  both  the 
ISO  and  CCITT  have  developed  archiiKturai  models  tor 
protocol  standards  and  the  ISO  has  developed  a  transport 
layer  protocol  called  the  Transport  Protocol  or  TP  Thu  TP 
offers  five  different  classes  of  operation  The  Ciass*4 
category  is  very  similar  to  the  OoO  s  TCP  The  existence  of  a 
commercial  transport  protocol  which  rs  different  from  the 
OoO  standard,  however,  has  raised  some  probitms  for  tne 
DoO  Conern  has  been  expressed  m  certain  areas  of  the 
private  sector  over  their  abthty  to  support  two  different 
.standards,  tne  question  has  been  raised  as  to  whether  or  not 
It  IS  cost  effective  for  the  OoO  to  utilize  a  standard  which  is 
ditferent  from  the  commercial  one  To  resolve  these  quet 
tions.  the  OoO  requnted  the  National  Academy  of  Science 
(NASI  \3  evaluate  both  protocols  against  OoO  requtrtments 
and  determine  whether  or  not  the  OoO  could  uM  the 
commercial  TP  m  lieu  of  TCP 

The  NA$  nai  not  concluded  its  study  as  ytt  but  *t  nas 
reaentd  the  conclusion  mat  the  TCP  and  the  TP  a>< 
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1)  Pruml  UmIii  m  »TF)t  proctss  of  Otfmmg  mt  Mrvict  tnO 

mtciWMsiii  H.  .iKOtieftt.  and  unpttmomtog  mt  proiecoi  m  a 
iMOO-ordtr  lanQuaot 

2)  fMKil  will  provtdt  mt  cipaOiiity  for  mttractivt 

and  automattd  "watk-mroughs'’  and  iptciai  analysis  of  mt 
protocols  to  ttst  for  sudi  condittons  as  stif-consisttncy.  statt 
rtacnabifity.  and  statt  lumomp** 
lupliMMMlM  Miai^Ttsttno  iht  protocol  for  conformanct  to  mt 
strvict  spies  and  now  wtd  It  ptrforms  mt  strvicts 
4)  Cttaroti  mummrnm  canMcaita-CtrtifyinQ  mat  a  ustr  t  impit. 
mtmation  of  a  protocol  performs  corrtetly  against  mt 
iaooratory  s  standard  tmpltfntnutton 
Si  VMlitita  aai  «trMcilia«>^oeidurts  for  providing  mt  laOoraiory 
standard  protoeei  agamst  wincn  omtr  impitmtntations  art 
ttsiid 

H  OMiimaiia  tMM^^ovidmg  support  for  ctntral  cenfigurattoo 
control  of  ad  OeO  protocol  unpitmaniations 


functionally  tquivaltnt  m  all  rtsptets.  No  forma!  rKorn* 
mtfKiatioriS  fiavt  bttn  formuiaitd  as  y«t  and  it  was  tapoettd 
that  tht  Acadtmy  s  final  report  will  have  been  compitttd  m 
OKtmbif  1914  Thts  study’s  conclusion  could  have  far- 


reaching  effects  on  the  OoO  protocol  standards  program  and 
the  impiefflentation  of  its  data  networks  as  well 

firofoco/  Ttst  Libcrmry 

An  important  consideration  m  the  DoO  program  is  protocol 
testing  To  this  end.  plans  have  been  developed  by  OCA  for  a 
protocol-testing  laboratory  to  be  located  at  the  Cefenst 
Communications  EnginHnng  Center  in  Reston.  VA  The 
purpose  of  this  test  facility  is  shown  in  Table  X  Figure  3 
depicts  a  preliminary  view  of  the  laboratory  layout 
The  laboratory  hardwarc/software  development  and  im¬ 
plementation  will  be  accomplished  m  three  phases.  The 
implementation  of  this  laboratory  will  proceed  along  the 
lines  indicated  m  the  paragraphs  below 
Phase  1  will  provide:  1)  a  basic  protocol  development 
minicomputer,  which  wit!  include  peripheral  storage  along 
with  Its  operating  system,  editors,  lar^uage  compilers  and 
assemblers,  and  other  basic  software  tools  2)  three 
interactive  work  station  terminals  (smart  terminals)  which 
will  allow  the  protccoi  developer  and  tester  access  to  all 
latMjratory  functions:  3)  two  minicomputer  Target  machines’ 
for  use  in  testing  one  protocol  implen^tation  agamst 
another,  snd  4)  a  basic  coaxial-cable  local  network  for 
mterconnecting  all  components  into  an  mlegratid  system 
Phase  2  wilt  provide  1)  thrM  additional  work -station 
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terminals.  2}  a  second  minicomputer  to  be  used  for  m-dcpth 
protocol  analysis  provided  by  special-purpose  software 
packages  such  as  an  interactive  state  machine  interpreter, 
automated  test  generator,  m-depth  state  machine  analysis 
programs,  and  3)  two  additional  target  machines  to  provide 
the  capability  for  simultaneous  protocol  testing  (testing  more 
than  one  protocol  at  the  same  time) 

Phase  3  will  procure  and  impittneni  small  minicomputers 
to  provide  the  function  of  network  gateways  to  other 
networks  such  as  the  DON  and  ARPANET  This  will  give  users 
the  capability  to  test  their  protocol  implementations  running 
at  their  own  facility  against  the  DoO  standard  protocol 
running  on  one  of  the  target  machines  m  the  laboratory  A 
special  graphics  terminal  with  a  hard-copy  printer  may  be 
procured  to  provide  detailed  graphic  I/O  of  protocol  designs 

Oitiir  StMiard  AdfvHiM 

NATO  Stindirds  Coordtnuion 

Another  standardization  area  which  requires  OCAS  partici¬ 
pation  and  activity  results  from  the  NATO/ United  States 
relationship  Here  again.  OCA  s  responsibilities  and  Ktivities 
are  dicutcd  by  public  taw  and  OoO  policy  Public  law  94-3S1 
decrees  that  equipment  procured  for  U  S  forces  m  Europe 
should  be  standardized  or  at  least  interoperable  with 
equipment  used  by  other  members  of  NATO  This  pubhc  law 
IS  supported  by  the  OoO  policy  of  rationalization  with  NATO 
member  telecommunications  facilities  (OoOO  20tG  7)  which 
states  that  the  U  S  shall  adhere  to  U  S  -ratified  STANAGS 
when  designing  or  procuring  telecommunications  equipment 
lA  STANAO  IS  a  NATO  Standardization  Agreement  i 
The  OCA  does  not  interface  difKtty  with  NATO  on 
communications  standardization  matters  but  rather  works 
throi^h  the  U  S  Military  Communications-Electronics  Board 
and  the  Joint  Standardization  Group  for  Tactical  Command 
Control  and  Communications  Systems  These  two  bodies  are 
chartered  to  provide  United  States  input  to  NATO  standards 
committHS  after  service  and  agency  coordination  They  are 
responsibfe  among  other  things  '  r  provtdmg  a  US 
position  on  NATO  Standardization  Agreements  (STANAOS)  m 
the  commumcationt  fttetromes  area  A  member  of  the  OCA 
Standards  Office  staff  is  a  working  member  of  these  two 
groups  and  me  Otf«ce  generally  becomes  the  focsi  point  ter 
coordinating  NATO  communicaiioni  eleftromcs  documents 
within  DCA  Once  the  U  S  has  ratified  a  commumcatmns- 
related  STANA6  the  OoO  policy  ?s  that  users  impiemtni 
those  parameters  contained  therein  wnicn  are  essenitai  for 
imerepffibitity  Such  Ktion  may  require  either  the  adoption 
of  a  nongovernment  standard  me  preparation  d  a  new 
military  standard  or  specificai«ort  or  the  addition  t?  or 
Charge  to  parimete»s  in  an  t usting  mitiiary  itandaid  an  of 
wtueft  Kitons  impKl  duKtly  upon  the  Standards  Officf 

anothr  ■mpoftanl  sianuardicaiion  a‘#a  Outside  of  the  OoO 
‘S  thif  UftitfS  States  federal  Tete£ommur*K:at»ons  SiancarCi 
P'ogram  This  program  managed  py  me  Nationat  Com 
munications  System  tliiCS»  yffxf  has  sfw  obfective  of 
rostfiirig  infeioperabihty  Of  Government  leiecom 

municatiorrs  networks  7hr  NCS  achieves  m.-s  oOfeCture 
targt/y  by  momtonrsg  the  activities  of  intemaiionat  and 
naitonai  standardization  group-.  then  adopting  then 


standi'ds  for  use  m  the  Federal  governrr  ent  Coordination  is 
maintained  with  the  participating  Federal  agencies  through  a 
Fedcra'  Teiecommurticaiions  Standards  CommittiHt  Liaison 
with  the  OoO  standardization  program  i$  mamtaintd  oy 
having  the  hud  of  the  OCA  Standards  Office  as  the  OoO 
representative  to  this  group  Also  the  OCA  Standards  Office 
has  been  designated  me  focal  point  for  coordinating  Federal 
standards  wiihm  OoD  A  critical  point  here  is  mat  me  OoO  is 
a  very  important  participant  m  the  Federal  Telecommunica¬ 
tions  Standards  Program,  and  every  attempt  is  made  on  this 
program  to  ensure  that  Federal  standards  proiicts  are 
acceptable  to  the  OoO  prior  to  their  being  finalized  as  Federal 
standards. 

Nongovtrnmnt  $tifidird$  ActmUts  of  OoO 

Nongovernment  standards  arc  those  standards  which  are 
developed  outside  of  the  Federal  government  and  are 
designed  primarily  for  commercial  use  This  class  of 
standards  is  citrcmciy  important  the  DoO  because  they 
are  used  as  a  basis  for  the  design  of  commercial  equipment 
and  the  implementation  of  communications  networks  both 
on  a  national  and  international  basis  The  DoO  has  a  great 
need  to  use  such  commercial  equipment  and  communica¬ 
tions  facilities  First,  consider  the  question  of  communi¬ 
cations  survivability  The  survivability  quotient  of  military 
networks  increases  with  the  number  and  Client  of  fKiliiies 
available  The  more  easily  military  networks  mieroperau 
with  commercial  networks  the  gieater  the  ch.snces  wilt  be 
for  sufvivabiiiiy  of  the  nations  communications  assets 
during  times  of  crisis  Second  the  OoO  very  often  fines  it 
more  economical  to  leas#  commumcatiens  services  than  le 
engineer  and  build  new  fKihties  In  fact,  the  amount  of 
leased  services  used  b/  the  DoO  ts  surprisingly  high  Thud 
the  OoO  finds  it  eitrtmeiy  advantageous  to  avar'  itstif  of  off- 
the-shelf  commercial  equipment  Such  an  option  m  addition 
to  providing  the  OoO  with  economies  and  fitubiiity  »n  me 
precurtmeni  of  equipment  considerably  cases  the  logistics 
0!  providing  spares  maintenance  and  tfairung  The  above 
advantages  to  the  OoD  a  e  considefabty  enhanced  tf  OoD 
requirements  art  reflected  m  the  provisions  of  the  com¬ 
mercial  standards  that  guide  the  design  of  comme  cia! 
equipments  and  networks 

SwMuzy 

in  Summary  the  OoO  has  eitensive  commumcai'cns 
requirements  The  impiemeniation  of  facilities  to  vat'Sfy 
these  requiftmenis  will  not  m  feasible  unless  these  .mpie- 
meniai.ons  are  based  upon  a  sound  sta?'dards  program 
Aes^siveness  to  military  rtouirementi  intfroperabiMfy 
economy  and  perforrnance  m  a  mih'ity  envuonment  are  the 
prime  o6?ect«.e»  The  OoO  f^s  estabiitneo  me  Defense 
StanqarfliZlfion  Ftogram  to  achieve  ^r^♦tf  obttct'ves  unoer 
this  pingram  the  OCA  nas  been  assignee  -ne  •espc'rsibi”', 
fpr  developing  iong  naui  commumcaiiOhs  star^da-Zs  nhvr 
me  JTC'A  nis  the  'esponsibititv  for  erve<dr‘''g  tacf^ca 
vttndaids  These  two  hj.v  ’ht  -evpz'? 

thlity  to  develop  common  standards  to  promote  intf‘cp.e-a 
bihty  betwern  ?o«g  haul  and  tact«c»r  cemmu^tcition* 

The  OoOn  overall  poitCy  »s  to  ut  !«.*#  comme-cii’  i*a*Za  's 
wherever  posubif  if  SuCh  use  does  no*  compfomut  1 

requirements  To  achieve  ob,eciivf  'he  DeD  acfi.i-.'y 
participates  m  commercial  vtandaids  pfCK-eedirg*  r 
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view  to  introducing  the  requirements  into  the  commercial 
standardization  process.  The  DoD  also  has  urgent  data 
communications  requirements,  and  has  expended  consider¬ 
able  resources  on  defining  these  requirements  and  investigat¬ 
ing  techniques  for  satisfying  them.  It  is  currently  pursuing 
the  development  of  data  protocol  standards  to  complement 
Its  efforts  in  the  development  of  data  communications 
systems.  Here  again,  these  standards  must  take  into  account 
the  rigors  of  providing  communications  in  a  military 
environment.  The  DoD  also  strongly  supports  the  develop¬ 
ment  of  commercial  protocol  standards  and  will  attempt  to 
use  them  wherever  their  use  does  not  compromise  essential 
military  requirements  In  support  of  the  foregoing,  the  DoD 
has  established  a  vital  program  for  the  development  and  test 
of  data  protocol  standards.  The  Defense  Communications 
Agency  has  been  designated  as  Executive  Agent  for  this 
program.  The  DoD  will  coordinate  its  efforts  with  the 
National  Bureau  of  Standards  m  an  attempt  to  reconcile 
militaiy  standards  with  commercial  standards,  and  it  will 
make  strong  efforts  to  coordinate  its  activities  with  NATO  as 
well 


Philip  S.  Selviggi  entered  the  military  service  m  1943  and  was 
discharged  from  the  United  States  Air  Force  in  1946  where  he  had 
served  as  a  communications  and  radar  officer  He  received  his  B  E  E 
degree  from  Brooklyn  Polytechnic  Institute  m  June  1947  and  a 
Masters  Degree  in  Electrical  Engineering  from  Stevens  Institute  of 
Technology  in  June  1954 

Shortly  after  gradua'mg  from  BPI  Mr  Selvaggi  lomed  I  T  T  Labs 
in  Nutley  NJ,  where  he  did  design  work  on  PCM  digital  telephone 
switching,  and  missile  systems  from  1949  to  1956  From  1956  to  1963 
he  served  with  the  Missile  and  Surface  Radar  Division  at  the  RCA 
Moorestown  Rant,  where  he  was  manager  of  the  Signal  Processing 
Skill  Center  which  was  involved  with  the  design  and  development  of 
precision  tracking  radars  and  advanced  development  techmquts  lor 
radar  systems 

Mr  Selvaggi  left  RCA  m  March  1%3to  lom  NASA  s  Manned  Space 
Flight  Program  as  assistant  director  of  system  integration  on  the 
Apollo  Program  In  June  1964  he  joined  OCA  where  he  served  as 
head  of  the  DCS  Systems  Engineering  Directorate  until  1974  Since 
that  time,  he  has  served  as  chief  of  the  Interoperability  and 
Standards  Office  primarily  involved  with  developing  standards  for 
DoD  communications  systems  Since  1982.  he  has  become  heavily 
involved  in  developing  OoO  protocol  standards  and  presently  se'^ves 
as  chairman  of  the  OoD  Protocol  Standards  Steering  Group  which 
oversees  the  development  of  protocol  standards  for  DoO  data 
communications  systems  ■ 
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SECTION  3.  BACKGROUND 

3.1  Brief  History  of  the  DDN 

The  ARPANET  was  the  first  packet-switching  network.  This  network  was  designed 
under  a  1969  DARPA  research  and  development  program.  Initially  the  ARPANET  was 
an  experimental  network  built  to  test  the  concepts  of  packet  switching  and  resource 
sharing.  As  the  ARPANET  matured,  users  with  operational  requirements,  rather  than 
experimental  requirements,  began  to  use  it. 

By  1975  there  were  many  operational  users  of  the  ARPANET;  therefore,  responsibility 
for  its  operation  was  traasferred  to  the  Defense  Communications  Agency  (DCA). 

In  April  1982,  as  a  result  of  an  intensive  internal  study  of  alternative  sjrstems,  the  DoD 
directed  that  the  Defense  Data  Network  (DDN)  be  implemented  as  the  DoD  common- 
user  data-communications  network,  based  upon  ARPANET  technology  and 
architecture. 

In  1983,  DCA  divided  the  ARPANET  into  two  separate  networks,  the  ARPANET  and 
the  MILNET,  thereby  forming  the  unclassified  segment  of  the  DDN. 

Both  networks  are  managed  by  DCA,  although  the  ARPANET  remains  a  DARPA 
research  and  development  network,  while  the  MILNET  and  other  segments  of  the  DDN 
are  operational  military  networks.  Readers  who  would  like  a  more  detailed  overview  of 
the  DDN,  including  a  description  of  the  backbone  equipment  and  configuration,  should 
consult  the  DDN  Information  Brochure  available  from  the  DDN  Network  Information 
Center  (NIC)  or  the  DDN  Program  Management  Office  (DDN  PMO). 

3.2  DoD  Architectural  Model 

Figure  3-1  shows  a  graphic  representation  of  the  architectural  model  of  the  DoD 
protocol  suite.  The  architecture  is  similar  to,  but  not  identical  with,  the  International 
Standards  Organization  (ISO)  Open  Systems  Interconnection  (OSI)  architecture.  (See 
Computer  Networks,  Vol.  7,  No.  5,  p.  293-328  (Oct.  1983)  for  a  discussion  of  the  DoD 
Internet  Architecture  Model.) 
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SECTION  4.  PROTOCOL  CONFIGURATION  MANAGEMENT  OF 
THE  DDN 

4.1  The  DDN  Program  Management  Office  (DDN  PMO) 

The  DDN  PMO  is  responsible  for  the  overall  management,  operations,  and  policy 
guidelines  for  the  DDN.  It  assists  new  military  subscribers  in  bringing  their  computers 
and  related  equipment  onto  the  DDN.  It  also  manages  the  ARPANET  research  and 
development  network  on  behalf  of  DARPA. 

The  DDN  PMO  provides  many  services  to  network  users  or  potential  network 
subscribers.  It  is  responsible  for  keeping  the  network  up  and  running,  providing  users 
with  assistance,  setting  policies,  anticipating  growth  and  expansion,  providing 
configuration  management  and  control,  assisting  new  subscribers  with  protocol 
implementation  and  testing,  and  advising  subscribers  on  the  selection  of  interface 
equipment  and  software. 

The  DDN  PMO  also  manages  the  access  control  and  security  of  the  network  backbone, 
and  provides  liaison  to  host  and  node  contacts  and  military  sponsors.  In  addition  it 
provides  technical  management  of  contracts  for  services,  equipment,  and  software 
obtained  from  outside  corporations  and  vendors. 

There  are  two  major  network  services  on  the  DDN:  the  Network  Information  Center 
(NIC),  provided  by  SRI  International  (SRI),  Menlo  Park,  CA,  and  the  Network 
Monitoring  Center  (NMC),  provided  by  BBN  Communications  Corporation  (BBNCC), 
Cambridge,  MA.  These  services  are  supported  under  contracts  from  the  DDN  PMO. 

A  third  service,  DCA  Code  B641,  the  Subscriber  Requirements  and  Integration  Branch, 
with  representatives  from  each  branch  of  the  military  service  as  well  as  other  sponsored 
government  agencies,  assists  new  network  subscribers  in  assessing  their  needs  for 
attaching  equipment  to  the  network. 

DCA  Code  B650,  the  Data  Operations  Division  of  the  DDN  PMO,  has  responsibility  for 
management  of  all  the  networks  that  make  up  the  DDN,  including  the  MILNET  and 
the  ARPANET.  All  operational  matters  of  the  DDN  should  be  referred  to  this  office. 
Code  B650  is  also  responsible  for  coordinating  operational  matters  within  the  DDN 
PMO  itself,  as  well  as  with  other  branches  and  divisions  of  the  DCA. 

To  provide  operational  management  support  for  the  DDN  networks.  Code  B650  has 
designated  a  person  at  the  DDN  PMO  to  act  as  the  primary  point  of  contact  (POC)  for 
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operations  for  each  of  the  DDN  networks.  Contact  the  NIC  on  (800)  235-3155  for  the 
names  of  these  persons. 

4.2  DDN  Configuration  Management 

DDN  network  configuration  management  is  under  the  control  of  the  Configuration 
Management  Branch,  DCA  Code  B602B. 

4.2.1  The  Configuration  Control  Group  (CCG) 

Matters  pertaining  to  configuration  management  of  the  DDN  are  decided  by  the 
Configuration  Control  Group  (CCG).  The  CCG  is  chaired  by  the  DDN  PMO  Technical 
Manager  and  is  made  up  of  the  DDN  PMO  Division  Chiefs.  Trouble  reports,  incident 
reports,  software  patch  requests,  and  requests  for  network  configuration  changes  are 
reviewed  and  approved  or  disapproved  by  this  group. 
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1.0  INTRODUCTION 

1.1  The  purpose  of  this  document  is  to  define  the  interfaces  of  the 
BLACKER  Front  Ends  (BFE)  .  This  document  will  define  the  services  used 
on  the  network  or  ciphertext  side  where  the  BFE  interfaces  to  the 
Defense  Data  Network  (DDK)  and  will  define  the  services  offered  on  the 
host  (host  or  gateway)  or  plaintext  side. 

Host  Network 

Plaintext  Ciphertext 

Red^Side  Black^Side 


I  HOST  OR  I _ I  BFE 

I  GATEWAY  I  I 


DI^  i 
PSN  1 


1.2  The  BFE  acts  as  a  switch  (DCE)  on  an  X.25  network.  As  such  the 
BFE  offers  an  X.25  Standard  Service  interface  to  the  host.  Because  of 
the  additional  security  functionality  of  the  BFE,  there  are  additional 
requirements  on  the  interface  at  levels  above  the  X.25  layer.  These 
additional  requirements  as  %rell  as  the  2q>ecific  details  of  the  X.25 
interface  are  defined  in  this  document. 

1.3  The  following  terminology  will  be  used  in  this  document.  Units  of 
information  at  the  link  level  will  be  referred  to  as  frames.  Units  at 
the  network  (X.25  level  3)  level  will  be  referred  to  as  packets. 

Units  at  the  IP  level  will  be  referred  to  as  datagrams.  Information 
passed  to  the  actual  destination  may  be  referred  to  as  messages  with 
an  appropriate  adjective  as  in  ICMP  message  or  AMPE  message. 

1.4  The  BLACKER  system  on  QDN  uses  the  X.25  interface  as  a  local 
interface  only.  This  means  that  the  type  of  service  offered  does  not 
provide  the  end-to-end  services  of  X.25.  The  BFE  will  offer  a  version 
of  DON  X.25  Standard  Service  as  defined  in  the  DDN  interface  document 
dated  Dec  1983  with  the  restrictions  and  modifications  defined  in  this 
document.  This  interface  will  further  conform  except  as  described 
below  with  FIPS  PUB  100  dated  6  July  1983  and  CCITT  reconnendation 
X.25  dated  1980.  The  BFE  will  not  provide  any  support  for  BBN  1822 
inter  faces . 

1.5  In  this  docum«it,  references  to  the  Administration  refer  to  the 
Defense  Communication  Agency. 


1.6  All  values  for  fields  defined  in  this  document,  unless  otherwise 
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designated,  are  decimal  values.  Ihese  values  will  be  sent  by  the 
binary  representation  of  the  decimal  value  unless  otherwise  noted. 

2.0  HOST/RED-SIDE  INTERFACE 

2.1  PH^ICAL  LEVEL 

The  BFE  will  conform  to  the  following  specifications: 

1.  ’’DEFENSE  DATA  NETWORK  X.25  HOST  INTERFACE  SPECIFICATION”  D.C.A., 
DECEMBER  1983 

2.  EIA  STANDARD  RS-449  NOVEMBER  1977 

3.  MIL-SID-188-114  MARCH  1976 

The  BFE  will  support  the  signals  as  listed  on  Table  B~2  of  DDN  X.25 
SPEC.  Optional  signals  supported  will  be  CCITT  ID  141  and  142  on  the 
host  side. 

In  RS-449  terms,  the  BFE  will  si^jport  all  Category  I  circuits  in  the 
balanced  mode.  The  BFE  will  also  support  all  TYPE  SR  mandatory 
circuits  for  synchronous  primary  channel  operation  (  see  RS-449  fig 

5.1  )  .  The  RS-449  37 -position  connector  with  a  GLENAIR,  INC.  (or 
equal)  backshell  will  be  used. 

The  BFE  will  present  a  Data  Communications  Equipment  (DCE)  interface 
to  the  host. 

The  BFE  will  operate  at  speeds  from  1.2  to  64  kilobits  per  second. 

Data  timing  will  originate  at  the  DCE.  RT  will  supply  the  data  strobe 
for  RD.  ST  will  supply  the  data  request  for  SD,  and  TT  will  supply 
the  data  acknowledge/data  strobe  for  SD.  This  inplicMi  that  the  DCE 
will  control  data  transfer  rates  via  RT  and  ST,  mnd  the  Data  Terminal 
Equipment  (DTE)  will  use  ST  to  generate  the  data  strobe  signal, TT. 

The  network  DCE  supplies  timing  to  the  BLACKER  DTE  and  the  BLACKER  DCE 
supplies  timing  to  the  host  DTE.  Note:  The  above  signal  names  RT,  RD, 
etc.  are  related  to  the  RS-449  names  used  below. 

Only  full  duplex  synchronous  cperation  will  be  supported. 

Interface  signal  electrical  characteristics  will  be  as  defined  by 
MIL-STO-100-114.  Interface  signal  fuix:tlons,  directions,  and  pin 
assignments  will  be  as  defined  in  RS-449, 


The  KC-04A  is  RS-449  conpatible  in  terms  of  signal  conventions. 
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LISTING  OF  SIGNALS  SUPPORTED  BY  THE  BFE  RED  SIDE 


PIN 

RS-449  ABBREVIATION 

DCE  IS 

1 

SHIELD 

NC 

2 

SI 

+5 

3 

SPARE 

4 

SD 

BR 

5 

ST 

BG 

6 

RD 

BG 

7 

RS 

BR 

8 

RT 

BG 

9 

CS 

BG 

10 

LL 

UR 

11 

DM 

BG 

12 

TR 

BR 

13 

RR 

BG 

14 

RL 

IB- 

15 

IC 

-5 

16 

SF/SR 

IB-»- 

17 

TT 

BR 

18 

TM 

UG 

19 

SG 

CIRCUIT  GROUND 

20 

RC 

DCE  CIRCUIT  GROUND 

21 

SPARE 

22 

SD  (  see  4  ) 

23 

ST  (  see  5  ) 

24 

RD  (  see  6  ) 

25 

RS  (  see  7  ) 

26 

RT  (  see  8  ) 

27 

CS  (  see  9  ) 

28 

IS 

IB+ 

29 

DM  (  see  11) 

30 

TR  (  see  12) 

31 

RR  (  see  13) 

32 

SS 

IB- 

33 

SQ 

♦5 

34 

NS 

IB- 

35 

TT  (  see  17) 

36 

SB 

-5 

37 

SC 

DTE  CIRCUIT  GROUND 
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ABBREVIATIONS  OTHER  THAN  RS-449  SIGNAL  NAMES 


GND 

CHASSIS  GROUND 

NC 

NO  CONNECTION 

-5 

PIN  PROVIDES  MINUS  FIVE  VOLTS  (  MARK,  OFF, 

1  FOR  UNBAL  ) 

+5 

PIN  PROVIDES  FIVE  VOLTS  {  SPACE,  (MI,  0  FOR 

BAL  cm.  UNEV<X,  ) 

IB- 

PIN  IS  OPEN,  INTERNAL  BIAS  OF  MINUS  FIVE  VOLTS 

IB-»- 

PIN  IS  OPEN,  INTERNAI.  BIAS  OF  FIVE  VOLTS 

BR 

BALANCED  RECEIVER 

UR 

UNBALANCED  RECEIVER 

BG 

BALANCED  GENERATOR 

UG 

UNBALANCED  GENERATOR 

2.2 

LINK  LEVEL 

The  BFE  will  conform  to  the  following  Link  Level  specifications: 

1.  "DEFENSE  DATA  NETWORK  X.25  HOST  INTERFACE  SPECIFICATIW,  D.C.A., 
DECEMBER  1983 

2.  •'INTERFACE  BETWEEN  DATA  TERMINAL  Es^IPMENT  (DTE)  AND  DATA  CIRCUIT 
TERMINATING  EQUIPMENT  (DCE)  FOR  TERMINALS  OPERATING  IN  THE  PACKET 
MODE  ai  PLmiC  DATA  NETWORKS",  RECOMMENDATION  X.25,  CCITT,  1980 

3.  "COMMUNICATION  PROOUCTS  HANDBOOK",  WESTERN  DIGITAL  CORP.,  JUNE  1984 

At  Level  2,  the  BFE  will  use  the  DC^I  X.25  Hi^  Level  Data  Link 
Control,  Link  Access  Procedure- Balanced  (  HDLC-LAPB  )  Interface 
protocol . 

On  the  host/red  side  the  BFE  will  be  a  DCE. 

The  interface  specified  in  Bolt  Beranek  and  Newman  Inc.  (BBN)  Report 
No.  1822  will  not  be  supported. 

The  HDLC-LAPB  interface  in  the  BFE  will  be  impleniented  using  the 
Western  Digital  WD2511AN-05  Packet  Network  Interface  chip.  NOTE:  The 
Defense  Communications  Engineering  Center  (DCEC)  certification  of  this 
chip  is  still  pending.  This  chip  handles  bit  oriented,  full  dqplex 
serial  data  coanunications  on  its  Level  1/Level  2  interface  side.  The 
conputer  interface  side  ures  direct  memory  access. 

The  "Transparent  Modes"  offered  by  the  WD2511  chip  will  not  be  used. 
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2 . 3  PACKET  LEVEL 

2.3.1  Ihe  BFE  will  conform  to  tlie  following  Packet  Level 
specifications  except  as  incacated  below.  Page  references  are  to 
specification  1.  Paragraph  references  to  specification  1  begin  with  a 
D  (as  D2. 1.1.1) . 

1.  "DEFENSE  DATA  NETWORK  X.25  HOST  INTERFACE  SPECIFICATION",  D.C.A., 
DECEMBER  1983 

2.  "INTERFACE  BETWEEN  DATA  TERMINAL  E^^IPMENT  (DTE)  AND  DATA  CIRCUIT 
TERMINATING  EQUIPMENT  (DCE)  FOR  TERMINALS  OPERATING  IN  THE  PACKET 
MODE  PUBLIC  DATA  NETWORKS",  RECOMMEI«)ATIC»I  X.25,  CCITT,  1980 

3.  "INTERFACE  BETWEEN  DATA  TERMINAL  EQUIPMENT  (DTE)  AND  DATA  CIRCUIT 
TERMINATING  EQUIPMENT  (DCE)  FOR  OPERATION  WITH  PACKET- SWITCHED  DATA 
C0^WUNICATI0NS  NETWORKS",  FED-STD  1041;  FIPS  PUB  100,  6  JULY  1983 

2.3.2  (pg.3)  Only  DDN  Standard  Service  will  be  offered.  No  provisions 
for  Basic  Service  will  be  made.  Any  call  requests  indicating  Basic 
Service  will  be  rejected. 

2.3.3  (pg.6)  Only  physical  addressing  will  be  supported.  All  BFE 
ports  will  be  assign^  a  physical  address  by  the  Administration.  The 
address  will  be  12  BCD  digits.  The  address  will  conform  to  the  format 
defined  in  D2. 1.1.1  with  the  foi^^wing  rMtrictions.  The  F  flag  will 
be  0.  All  addU'esses  will  be  12  BCD  digits,  sub-addresses  will  not  be 
supported.  Requests  for  Logical  Addressing  facilities  will  receive  a 
CLEAR  INDICATION  packet  with  an  iqspropriate  diagnostic  code  (146)  . 

2.3.4  (pg.8)  In  D2. 1.2.1  for  the  Type  of  Service  facility.  Standard 
Service  must  be  selected  on  all  CALL  REQUEST  packets.  Failure  to 
iqpecify  Standard  Service  will  result  in  a  CLEAR  INDICATION  packet  with 
an  iqppropriate  diagnostic  code  (155) . 

2.3.5  (pg.lO)  In  D2.1.3,  Protocol  Identification,  DTEs  must  enploy  DoD 
standard  IP.  The  value  defined  for  IP  (11001100  binary,  CC  hex)  must 
be  present  in  the  CALL  REQUEST  packet.  Selection  of  a  different  value 
will  result  in  a  CLEAR  INDICATION  packet  with  an  qspropriate 
diagnostic  (156) . 

2.3.6  (pg.ll)  Negotiated  maximum  packet  size  of  1024  octets  is 
str<mgly  recoipmended  in  order  to  allow  an  IP  datagram  to  tit  within  a 
single  X.25  packet.  Maximum  pa^cet  sizes  of  128,  256,  512,  and  1024 
octets  will  be  supported  by  the  BFE.  A  packet  size  of  1024  is 
required  for  hosts  accredited  to  operate  at  multiple  security  levels. 

(See  2.4.4) 
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2.3.7  (pg.ll)  The  maximum  number  of  data  bits  in  a  c<xnplete  packet 
sequence  must  be  no  more  than  7168  (896  octets) .  An  atteopt  to  send 
more  than  896  octets  will  result  in  a  CLEAR  INDICATIC^  with  an 
appropriate  diagnostic  code  (39)  . 


2.3.8  (pg.A6)  The  D-bit  and  Q~bit  have  no  significance  to  the  BEE  and 
are  not  pass^  to  the  destination.  These  should  be  set  to  zero  by  the 
DTE. 


2.3.9  (pg.A7)  There  is  no  mipport,  for  Logical  Addressing.  Requests 
for  Logical  Addressing  facilities  will  receive  a  CLEAR  INDICATIC^ 
packet  with  an  appropriate  diagnostic  code  (146) . 


2.3.10  (pg.A9)  BLACKER  X.2S  addresses  are  derived  from  IP  addresses  as 
follows: 


The  IP  address  is  a  32  bit  quantity  that  can  be  thouQ(ht  of  as  two 
parts,  the  first  8  bits  define  the  network  and  the  remaining  24  bits 
are  network  iqpecific.  Eor  the  BEEs,  the  24  bit  host  field  will  be 
mapped  to  the  seven  BCD  digit  host  identifier  field  as  follows.  The 
first  bit  is  zero.  The  next  three  bits  map  to  the  first  BCD  digit, 
the  next  ten  bits  map  to  the  next  three  BCD  digits  and  the  last  ten 
bits  m^  to  the  last  three  BCD  digits.  The  mapping  is  a  value 
conversion  from  the  binary  representation  to  the  BCD  representation. 


The  D0N*RVN  will  be  a  class  A  network.  The  IP  network  number  for  the 
DON-RVN  is  21.  The  24-bit  host  field  will  be  defined  as  follows: 


0  12 
012345678901234567890123 


iOiPORT 


DOMAIN  ID 


BEE  ID 


m 
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The  lOf-RVN  is  an  X.25  network  s^pporting  a  version  of  IE>N  Standard 
Service.  The  X.25  address  consists  of  12  BCD  digits  defined  as: 

NNNN  F  DODDDOD 

where 

NNNN  is  a  network  identifier 

F  is  a  flag  indicating  whether  the  address  is  physical  or 

logical 

DDDDDDD  is  a  network  specific  address 

For  the  DOM-RVN,  NKNN  is  a  value  TBD«  initially  it  will  be  set  to 
0000.  F  is  0  indicating  physical  addressing.  DOCDDDD  is  directly 
napped  from  the  host  field  of  tlie  IP  address  where  the  first  digit  is 
the  port  ID,  the  next  three  digits  are  the  doqiain  ID,  and  the  last 
three  digits  are  the  intradonain  BFE  ID. 

The  napping  between  the  IP  host  field  and  the  X.25  network  specific 
address  is  as  follo%fs: 

0  1  2  2 

0  0  0  3 

IP: 

o\  A  A  / 

I  . . 

I  1  i 

x.25:  D  CCX)  DOD 


2.3.11  INTERRUPT  and  IKXEIRUPT  CONFIRMATION  packets  are  not  sqpported. 

2.3.12  DAXACRAM  service  is  not  supported. 

2.3.13  There  will  be  no  SMpport  for  PfltHANEKr  VIRTUAL  CIRCUITS.  All 
calls  will  need  to  be  establlidMd  via  CALL  REQUIOT  packets. 

2.3.14  Only  certain  X.25  facilities  will  be  supported. 

The  following  facilities  WILL  BE  supported  by  the  BFE: 

1960  CCITT  paragraph 

Nonstandard  default  window  size  7.1.2 

Nonstandard  default  packet  size  7.2.1 

Flow  control  parameter  negotiation  7.2.2 
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The  following  facilities  WILL  MOT  BE  supported  by  the  BEE: 


1980  CCITT  paragraph 

Extended  packet  sequence  numbering  7.1.1 

Default  Throughput  Class  Assignment  7.1.3 

Packet  Retransmission  7.1.4 

Incoming  Calls  Barred  7.1.5 

Outgoing  Calls  Barred  7.1.6 

One-way  logical  charmsl  outgoing  7.1.7 

One-way  logical  channel  incoming  7.1.8 

Closed  user  groqp  (all  varieties)  7.1.9-7.1.15 

Reverse  charging  7.1.16 

Reverse  charging  accqptanoe  7.1.17 

RPOA  selection  7.1.18 

Throu^lhput  class  negotiation  7.2.3 

East  select  7.2.4 

East  select  acceptance  7.2.5 

D-bit  modification  7.2.6 

Datagram  facilities  (all  varieties)  7.3 


2.3.14.1  For  selection  of  Flow  Control  Parameters  (packet  and  window 
size)  the  BFE  will  default  to  a  packet  size  of  128  octets  and  a  window 
size  of  2.  A  host  may  select  nonstandard  defaults  for  pacdcet  size 
between  128  and  1024  and  for  window  size  between  2  and  7.  For 
incoming  calls,  the  host  may  select  whether  or  not  the  BFE  will 
negotiate.  If  the  host  chooses  not  to  negotiate,  the  BFE  will  use  the 
defaults  for  all  calls.  If  negotiation  is  selected,  the  BFE  will 
offer  a  packet  size  of  1024  and  a  window  size  of  7;  the  host  may  then 
respond  with  a  smaller  size  if  desired. 

2.3.15  (Deleted) 

2.3.16  DIACNOSTICS 

2.3.16.1  The  BFE  passes  certain  diagnostic  information  back  to  the 
host  to  indicate  status  information  on  the  communication  path  and  to 
provide  security  related  information.  Diagnostic  information  is 
provided  when  the  BFE  becomes  aware  of  a  reportable  event.  However, 
there  is  no  guarantee  that  the  BFE  will  be  able  to  detect,  nor  report, 
all  anomalous  situations. 

2.3.16.2  Diagnostic  information  is  sent  in  the  diagnostic  field  in 
X.25  packets.  For  the  X.25  diagnostic  codes,  the  BFE  will  use  the 
values  defined  in  the  CCITT  recrommsndation  and  in  the  DON 
apecification  with  the  following  interpretations .  DON  code  128.  IMP 
Unsvailable.  will  indicate  that  the  DON  packet  switching  nods  to  %ihich 
the  BFE  is  connscted  is  unsvailable.  DON  code  137.  Remote  IMP  Dead, 
will  indicate  that  the  destination  BFE  ia  unreachable. 
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2.3.16.3  Diagnostic  information  related  to  Emergency  Mode  status  will 
be  passed  to  the  host  at  the  X.25  level.  DIAGNOSTIC  packets  will  be 
sent  by  the  BFE  with  the  following  diagnostic  codes: 

Code 

Entering  Emergency  Mode  224 
Leaving  Emergency  Mode  225 
Emergency  Mode  Window  Open  226 

CLEAR  INDICATION  packets  will  be  sent  by  the  BFE  with  the  following 
diagnostic  codes: 


Code 

Call  Failed- -Address  Translation  Information  Required  227 

Call  Failed- -Emergency  Window  Qpen,  BFE  not  in  Emergency  Mode  228 


The  host  commands  the  BFE  to  enter  Emergency  Mode  when  the  window  is 
opened  by  using  the  Emergency  Mode  Address  Facility  (2.3.17.3)  with 
the  address  set  to  all  zeroes. 

2.3.17  EMERGENCY  MODE 


2.3.17.1  One  aspect  of  the  BLACKER  system  operation  is  the  ability  to 
communicate  between  BFEs  in  the  absence  of  Access  Control  Centers 
(ACC)  and/or  Key  Distribution  Centers  (KDC) .  This  capability  is 
referred  to  as  Emergency  Mode.  The  use  of  Emergency  Mode  Involves  the 
host  in  some  of  the  processing.  Depending  on  a  BFE  start-up  parameter 
(si^jplled  when  the  BFE  was  in  communication  with  an  ACC  or  supplied 
via  BLACKER  Variable  Carrier  (BVC) ) ,  when  a  potential  for  Emergency 
Mode  exists,  either  the  BFE  will  automatically  enter  Emergency  Mode 
and  so  notify  the  host,  or  it  will  ask  the  host  via  the  X.25  codes 
defined  in  2.3.16.3.  The  host  must  then  command  the  BFE  to  enter 
Emergency  Mode  as  defined  in  2.3.16.3  and  2.3.17.3  and  the  BFE  will 
acknowledge , 

2.3.17.2  Additionally,  since  the  address  translation  table  described 
above  is  maintained  by  the  ACC  and  in  Emergency  Mode  the  BFE  may  not 
be  able  to  communicate  with  the  ACC,  a  host  is  limited  as  to  what 
other  hosts  it  may  communicate  with  v^le  in  Emergency  Mode.  The 
optional  X.25  facility  defined  in  2.3.17.3  allowing  a  host  to  provide 
the  address  translation  information  may  be  used  if  a  host  requires 
flexibility  beyond  these  constraints. 
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2.3.17,3  An  additional  optional  user  facility  will  be  supported.  This 
facility  will  allow  the  DTE  to  provide  the  DDN  address  (black  internet 
address)  of  the  destination  BFE  (see  section  3.5.3)  .  'Ihis  facility  is 
available  only  when  Emergency  Mode  is  enabled.  The  facility  code  is 
193.  The  format  is: 

0  1  11000001 

C  2  00000100 

T  3  32  “bit 

E  4  Black 

T  5  IP 

6  Address 


The  Black  address  will  be  stored  with  (from  diagram  in  2.4.2)  bits  0-7 
in  octet  3,  bits  8-15  in  octet  4,  bits  16-23  in  octet  5  and  bits  24-31 
in  octet  6.  Bit  0  will  be  the  leftmost  bit  of  octet  3,  etc.  Setting 
the  address  field  to  all  zeroes  indicates  that  the  BFE  should  enter 
Emergency  Mode  and  is  sent  in  response  to  the  BFE  message  advertising 
the  opening  of  the  Emergency  Mode  Window  (2.3.16.3) .  If  it  is 
necessary  to  provide  the  enter  Emergency  Mode  command  along  with 
address  translation  information  the  facility  will  appear  twice  in  the 
CALL  REQUEST  packet  with  the  enter  Emergency  Mode  command  appearing 
first . 

2.3.18  The  BFE  will  support  up  to  128  simultaneous  open  logical 
channels. 

2,4  INTERNET  PROTXXTOL  FEATURES 

2.4.1  In  addition  to  the  X.25  Interface,  the  BFE  requires  the  use  of 
IP  as  defined  in  MIL  STD  1777.  The  only  restrictions  on  the  use  of  IP 
are  as  follows: 

2.4.2  The  IP  address  is  a  32 -bit  value  consisting  of  a  network 
identifier  and  a  network  specific  host  field.  There  are  different 
formats  for  this  address.  The  DDN-RVN  is  a  class  A  network  (net 
number  21)  with  the  following  format: 

0  12  3 

01234567890123456789012345678901 

)  0 1  NET  I  HOST  1 

+  -  +  --f-  +  -  +  ~  +  -  +  --f-  +  -  +  -4--  +  -4--  +  -  +  -4--  +  -  +  -  +  -  +  -  +  -  +  -4--  +  ”  +  -  +  -  +  -.4^-  +  -  +  -  +  -  +  -  + 


2.4.3  The  host  connected  to  a  BLACKER  Front  End  will  have  a  Red  IP 
destination  address  for  the  datagram.  This  address  will  be  used  by 
the  host  to  doterraine  the  local  subnetwork  address  of  the  next  hop  on 
the  Red  Virtual  Network  (RVN) ,  the  network  comprising  all  hosts 
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connected  to  BFEs.  The  local  subnetwork  address  will  be  the  X.25 
address  corresponding  to  either  the  actual  Red  IP  destination  or  the 
IP  address  of  the  gateway  that  is  the  next  hop  to  the  destination. 

2.4.4  The  maximum  BLACKER  IP  datagram  size  is  896  octets.  IP 
datagrams  of  more  than  576  octets  should  only  be  sent  if  there  is 
assurance  that  the  destination  is  pr^ared  to  accept  the  larger 
datagrams.  An  IP  datagram  must  be  sent  as  an  X.25  complete  packet 
sequence  if  the  datagram  does  not  fit  within  a  single  X.25  packet.  A 
packet  or  complete  packet  sequence  must  contain  exactly  one  conplete 
IP  datagram.  If  IP  datagrams  are  sent  in  multiple  X.25  packets,  no 
more  than  32  incouplete  datagrams  (unfinished  packet  Sequences)  may  be 
sent  at  one  time.  Only  single  level  hosts  are  allowed  to  send 
datagrams  as  packet  sequences.  Hosts  accredited  to  send  datagrams  at 
multiple  security  levels  must  send  and  receive  datagrams  in  single 
packets.  Any  packet  received  from  such  a  host  with  the  M  bit  set  will 
result  in  the  call  being  CLEARed. 

2.4.5  All  IP  datagrams  must  contain  a  security  label  as  defined  in  the 
IP  security  option.  This  must  be  the  first  option  on  all  IP 
datagrams.  The  format  and  values  for  IP  Security  Option  fields  are 
taken  from  the  "Revised  Internet  Protocol  Security  Option  (IPSO) " . 
BLACKER  currently  makes  cryptographic  distinctions  based  on  the  four 
hierarchical  U.S.  classification  levels  and  four  non-hierarchical 
National  Access  Programs  as  defined  in  the  Revised  IP  Security  Option. 
In  addition,  BLACKER  is  designed  to  make  cryptographic  distinctions  on 
up  to  four  additional  hierarchical  U.S.  classification  levels  and 
twelve  additional  Special  Access  Programs  if  and  when  they  are 
specified. 

2.4.6  The  BFE  has  a  limited  amount  of  space  available  to  buffer 
datagrams.  For  datagrams  for  which  authorizations  already  exist  in 
the  BFE,  normal  flow  control  procedures  will  be  used.  For  datagrams 
which  require  communication  with  the  ACC,  the  BFE  will  only  guarantee 
the  buffering  of  at  least  five  datagrams.  These  datagrams  will  be 
held  pjendlng  the  response  from  the  ACC.  Since  the  receipt  of 
additional  datagrams  requiring  communication  with  the  ACC  may  overflow 
the  available  buffers,  such  additional  datagrams  may  be  discarded. 

2.4.7  The  BLACKER  System  supports  dual  (multiple)  homing  of  hosts  by 
providing  authorizations  between  all  BFEs  connected  to  the  source  and 
all  BFEs  connected  to  the  destination  hosts.  These  BFEs  each  have 
different  network  and  internet  addresses.  The  source  host  must 
provide  the  mechanism  for  selecting  the  communication  path  from 
multiple  addresses.  (BLACKER  does  NOT  support  the  Dual  Homing  of  its 
own  ACCs  or  KDCs.) 
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2.5  INTERNET  CONTROL  MESSAGE  PROTOCOL  FEATURES 

2.5.1  The  BFE  also  makes  use  of  ICMP  messages  to  indicate  certain 
information  to  the  host. 

2.5.2  The  BFE  will  respond  to  ICMP  ECHO  messages  with  ICMP  ECHO  REPLY 
messages . 

2.5.3  The  BFE  passes  certain  diagnostic  information  back  to  the  host 
to  indicate  status  information  on  the  communication  path  and  to 
provide  security  related  information.  Diagnostic  information  is 
provided  when  the  BFE  becomes  aware  of  a  rqportable  event.  However, 
there  is  no  guarantee  that  the  BEE  will  be  able  to  detect,  nor  rcqport, 
all  anomalous  sitixations. 

2.5.4  Diagnostic  information  will  be  passed  in  ICMP  messages.  A 
DESTINATION  UNREACHABLE  (type  3)  message  will  be  sent  when  a  Request 
Denied  message  is  received  by  the  BE'E  from  the  ACC.  Code  1-Host 
Unreachable  will  be  sent  if  the  Request  Denied  message  indicates  that 
the  destination  BFE  is  down.  Code  10 -Communication  with  Destination 
Host  Administratively  Prohibited  will  be  sent  if  the  Request  Denied 
message  indicates  that  access  is  denied. 
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3.0  NETWORK/BLACK-SIDE  INTERFACE 

3.1  This  section  describes  the  DON  interface  of  all  BLACKER  equipment 
connecting  to  the  DON. 

3.2  PHYSICAL  LEVEL 

The  BFE  will  conform  to  the  following  specifications: 

1.  "DEFENSE  DATA  NETWORK  X.25  HOST  INTERFACE  SPECIFICATION"  D.C.A., 
DECEMBER  1983 

2.  EIA  STANDARD  RS-449  NOVEMBER  1977 

3.  MIL-STD-188-114  MARCH  1976 

The  BFE  will  siipport  the  signals  as  listed  on  Table  B''2  of  DDN  X.25 
SPEC.  No  optional  signals  will  be  supported  on  the  network  side. 

In  RS-449  terms,  the  BFE  will  snjpport  all  Category  I  circuits  in  the 
balanced  mode.  The  BFE  will  also  support  all  TYPE  SR  mandatory 
circuits  for  synchronous  primary  channel  operation  (  see  RS-449  fig 
5,1  )  ,  The  RS-449  37 -position  connector  with  a  GLENAIR,  INC.  (or 
equal)  backshell  will  be  used. 

The  BFE  will  present  a  DTE  interface  to  the  network. 

The  BFE  will  operate  at  speeds  from  1.2  to  64  kilobits  per  second. 

Data  timing  will  originate  at  the  DCE.  RT  will  supply  the  data  strobe 
for  RD.  ST  will  supply  the  data  request  for  SD,  and  TT  will  si^ly 
the  data  acknowledge/data  strobe  for  SD.  This  isplies  that  the  DCE 
will  control  data  transfer  rates  via  RT  and  ST,  and  ttie  DTE  will  use 
ST  to  generate  the  data  strobe  signal, TT.  The  network  DCE  supplies 
timing  to  the  BLACKER  DTE  and  the  BLACKER  DCE  supplies  timing  to  the 
host  DTE.  Note:  The  above  signal  names  RT,  RD,  etc.  are  related  to 
the  RS-449  names  used  below. 

Only  full  duplex  synchronous  operation  will  be  supported. 

Interface  signal  electrical  characteristics  will  be  as  defined  by 
MIL -STD- 188 -114.  Interface  signal  functions,  directions,  and  pin 
assignments  will  be  as  defined  in  RS-449, 

The  KG-84A  is  RS-449  conpatible  in  terms  of  signal  conventions. 
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LISTING  OF  SIC^IALS  SUPPORTED  BY 
THE  NETWORK  SIDE  OF  THE  BFE 


PIN 

RS-449  ABBREVIATION  DTE  IS 

1 

SHIELD 

GND 

2 

SI 

IB+ 

3 

SPARE 

4 

SD 

BG 

5 

ST 

HR 

6 

RD 

BR 

7 

RS 

BG 

8 

RT 

BR 

9 

CS 

BR 

10 

LL 

-5 

11 

DM 

BR 

12 

TR 

BG 

13 

RR 

BR 

14 

RL 

-5 

15 

IC 

IB- 

16 

SF/SR 

+5 

17 

TT 

BG 

18 

TM 

IB- 

19 

SG 

CIRCUIT  GROUND 

20 

RC 

DCE  CIRCUIT  GROUND 

21 

SPARE 

22 

SD 

'  see 

4  ) 

23 

ST 

SCM 

5  ) 

24 

RD 

see 

6  ) 

25 

RS 

see 

7  ) 

26 

RT 

see 

8  ) 

27 

CS 

[  see 

9  ) 

28 

IS 

+5 

29 

DM 

[  see 

11) 

30 

TR 

f  see 

12) 

31 

RR 

[  see 

13) 

32 

SS 

-5 

33 

SQ 

IB+ 

34 

NS 

-5 

35 

TT  (  see  17) 

36 

SB 

IB- 

37 

SC 

DTE  CIRCUIT  GROUND 

ABBREVIATIONS  OTHER  THAN  RS-449  SIGNAL  NAMES 


GND 

NC 

-5 

♦5 

13 


CHASSIS  GROUND 
NO  CONNECTION 

PIN  PROVIDES  MINUS  FIVE  VOLTS  (  MARK,  OFF,  1  FOR  UNBAL  ) 
PIN  PROVIDES  FIVE  VOLTS  (  SPACE,  ON,  0  FOR  BAL  OR  UNBAL  ) 
PIN  IS  OPEN,  INTTRNAL  BIAS  OF  MINUS  FIVE  VOLTS 
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IB+  PIN  IS  OPEN,  INTERNAL  BIAS  OF  FIVE  VOLTS 

BR  BALANCED  RECEIVER 

UR  UNBALANCED  RECEIVER 

BG  BALANCED  GENERATOR 

UG  UNBALANCED  GENERATOR 

3.3  LINK  LEVEL 

The  BFE  will  conform  to  the  following  Link  Level  specifications: 

1.  "DEFENSE  DATA  NETWORK  X.25  HOST  INTERFACE  SPECIFICATION",  D.C.A., 
DECEMBER  1983 

2.  "INTERFACE  BETWEEN  DATA  TERMINAL  EQUIPMENT  (DTE)  AND  DATA  CIRCUIT 
TERMINATING  EQUIPMENT  (DCE)  FOR  TERMINALS  OPERATING  IN  THE  PACKET 
MODE  ON  PUBLIC  DATA  NETWORKS",  RECOMMENDATION  X.25,  CCITT,  1980 

3.  "COT'flUNI CATION  PRODUCTS  HANDBOOK",  WESTERN  DIGITAL  CORP.,  JUNE  1984 

At  Level  2,  the  BFE  will  use  the  DDN  X.25  Hig^h  Level  Data  Link 
Control,  Link  Access  Procedure-Balanced  (  HDLC-LAPB  )  interface 
protocol . 

On  the  IMP/black  side  the  BFE  will  be  a  DTE. 

The  interface  specified  in  Bolt  Beranek  and  Newman  Inc.  (BBN)  Report 
No.  1822  will  not  be  supported. 

The  HDLC-LAPB  interface  in  the  BFE  will  be  inplemented  using  the 
Western  Digital  WD2S11AN-05  Packet  Network  Interface  chip.  NOTE:  The 
Defense  Comsunlcations  Engineering  Center  (DCEC)  certification  of  this 
chip  is  still  pending.  This  chip  handles  bit  oriented,  full  duplcuc 
serial  data  communications  on  its  Level  1/Level  2  Interface  side.  The 
computer  interface  side  uses  direct  memory  access. 
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3.4  PACKET  LEVEL 

3.4.1  The  BFE  network  interface  to  DDN  conforms  to  the  DDN  interface 
specification  dated  December  1983. 

3.4.2  The  BFE  operates  with  a  Standard  Service  interface.  It  may 
operate  with  a  Basic  Service  interface  on  the  network  side  only. 

3.4.3  The  BFE  is  designed  to  operate  with  a  maximum  packet  size  of 
1024  octets  but  will  also  operate  at  128,  256  or  512  octets. 

Operating  with  a  maximum  packet  size  of  less  than  1024  octets  may 
significantly  impact  performance. 

3.4.4  The  BFE  does  NOT  make  use  of  INTERRUPT  service  and  does  NOT  set 
the  D-bit  or  Q-bit. 

3.4.5  For  the  protocol  identification  information  in  the  X.25  call, 
the  BFE  will  use  CC  hex  (11001100  binary)  to  Indicate  that  IP  is  the 
next  ler/el  protocol  and  C5  hex  (11000101  binary)  to  indicate  the 
absence  of  IP  and  that  the  next  layer  of  protocol  is  the  encryption 
layer . 

3.5  INTERNET  PROTOCOL  FEATURES 

3.5.1  The  BEE  will  send  IP  datagrams  of  up  to  1024  octets. 

3.5.2  The  BFE  may  not  use  an  IP  header  on  the  network  side  when 
sending  datagrams  across  a  single  Black  network.  This  will  be 
indicated  in  the  X.25  pv'otocol  field  as  stated  in  3.4.5.  This  applies 
ONLY  to  traffic  intended  for  decryption.  Traffic  destined  for  the 
Black  side  will  always  contain  an  IP  header. 

3.5.3  The  BEE  takes  the  1X)N-RVN  address  (2.3.10)  and  generates  the 
Black  IP  address  via  a  table  lookup.  There  is  a  table  In  the  BEE 
containing  the  addr€»ss  translations  for  the  BEE's  domain  and  some 
interdobiain  BEE  address  translation  information.  This  table  is 
maintained  by  the  Access  Control  Center  (ACC)  for  the  BEE. 

Optionally,  information  for  this  table  may  be  provided  by  the  host 
when  the  BEE  is  in  Emergency  Mode.  The  Black  IP  address  is  passed  to 
the  Black  side  for  the  Black  IP  datagram. 

3.5.4  The  Black  X.25  network  address  is  generated  from  the  Black  IP 
address  via  the  algorithm  defined  for  DDN.  The  BEE  will  support  the 
full  DDN  address  trariSlation  algorithm  for  both  physical  and  logical 
addresses . 

3.6  INTERNET  CONTROL  MESSAGE  PROTOCOL  FEATURES 

3.6.1  The  BEE  will  be  capable  of  receiving  all  ICMP  message  types  and 
of  generating  at  least  ECHO  REPLY,  PARAMETER  PROBLEM,  and  DESTINATION 
UNREACHABLE  messages. 
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SU3JECT:  Host-to-Host  Protocols  for  Pata  Communications 
Networks 


A  number  of  <!ata  communications  networks  are  operating  or 
under  develoonent  within  DoO,  without  adeouate  orovisions  for 
interooerabilitv.  AUTCOIM  II  is  exoected  to  become 
ooerational  during  FY  1980,  to  provide  comtron-user  data 
communications  service  for  DoO  computer  systems  and  oermit  a 
reduction  in  the  number  of  specialized  data  networks.  Plans 
are  under  way  to  incoroorate  within  AUTODIN  II  networks  such 
as  the  wvrMCCS  In tercomouter  Network  (Wi?J) ,  Intelligence  Data 
Handling  System  Communications  (TDHSC)  and  the  SAC  Digital 
'’etwork  (SACDI^M#  among  others.  Local  networks  such  as  the 
Community  On-Line  Intelligence  Network  System  (COINS)  end 
certain  tactical  networks  must  have  effective  AUTODIN  II 
interfaces. 


AUTCDIN  II  will  orovide  connectivity  for  a  wide  range  of 
systems,  but  the  tx>tential  for  information  exchange  hevond 
narrowly  defined  communities  will  be  limited  without 
aoorooriate  standards  for  internet,  host- to-host . 
terminal-to-host  and  other  orotocols.  As  the  need  to 
exchange  information  across  network  boundaries  increases, 
lack  of  common  protocol  standards  will  become  a  formidable 
barrier  to  interooerabili ty.  Technioues  in  which  the 
orotocols  of  one  network  are  translated  into  the  orotocols  of 
another  will  become  increasingly  unworkable  as  the  numoer  of 
orotocols  and  networks  reauiring  interooeration  increases. 

To  insure  interooerabil i ty  of  future  data  networking,  Z  am 
directing  the  adoption  of  a  set  of  OoO  standard  host-to-host 
orotocols  based  on  the  Transmission  Control  and  Internet 
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Protocols  (TCP/IP  version  4)  ievelooed  in  the  OARPA/DCA 
internetwork  comoiunity.  OoO  requirements  for  precedence, 
security,  and  community  of  interest  controls  will  be 
incorporated  within  the  standard  protocol  set.  Use  of  these 
protocols  will  be  mandatory  for  ail  packet-oriented  data 
networks  where  there  is  a  potential  for  host-to-host 
connectivity  across  network  or  subnetwork  boundaries. 
Case-by-case  exceptions  will  be  granted  only  for  networks 
that  can  be  shown  to  have  no  future  requirements  for 
interoperability.  Because  the  ho&t-to-host  orotocol  being 
develooed  for  AUTOOZN  II  evolved  from  an  early  version  of  TCP 
and  is  unsuitable  for  internetwork  operation,  the  AUTOOIN  ll 
TCP  will  have  to  be  upgraded  to  the  standard  protocol  set. 
Recognizing  that  there  may  be  cost  and  schedule  impacts  on 
the  AUTOOIN  II  program,  the  Defense  Communi cat  ions  Agency 
should  oerform  a  coat  tradeoff  analysis  to  determine  the 
ODtimum  time  for  this  transition.  DCA  should  provide  the 
results  of  this  analysis  by  April  1979. 

To  address  these  and  future  protocol  issues  and  promulgate 
appropriate  standards,  I  am  forming  an  OSD  Protocol  Standards 
Working  Grouo  chaired  by  the  Director,  Information  Systems. 

I  ask  each  addressee  to  nominate  a  representative.  Names 
should  be  orovided  by  8  January  1979  to  LTC  Wilcox 
(695-3287).  The  first  task  of  this  group  will  be  to  finalize 
details  of  the  standard  host-to-host  orotocol  set.  Draft 
specifications  for  these  protocols  will  be  available  in 
January  1979.  Final  specifications  should  be  distributed  by 
April  1979  following  review  by  the  working  group  and  testing 
by  OCA  and  DARPA.  At  that  time,  I  expect  to  promulgate  these 
sts^ndards  and  set  dates  for  their  adoption. 

The  Defense  Communications  Agency  is  designated  as  DoO 
Executive  Agent  for  computer  communications  protocols  and 
will  manage  the  implementation  and  development  and  evolution 
of  standard  host-to-host  protocols,  as  designated  by  the 
Protocol  Standards  Working  Grouo,  The  OCA  will  forward  to 
this  office  within  120  days  a  management  plan  for  carrying 
out  this  role. 


Qereld  P.  Dlnettn 
frincipil  Deputy 
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OZFCCTOFS  or  TMt  OITIIISE  ACENCZB 

SUBJECT:  DoO  Folley  on  StOAdnrdiUtloo  of  Reot^to^ot  Froteeola  for  Data 
Ca— unicatAona  Natworka 

Bafaraoeat  (a)  U3DRAI  Haao,  *loat*lo«4fo8t  Frotoeola  far  Data  CoMui.lea cions 
HatMorka,*  23  Dm  71 

(b)  OoO  Standard  Traaaaiaaian  Control  Frotoaal  Spaelfiaatien, 

Jan  BO 

(a)  OoO  Standard  Zntamat  FrotoooX  Spaalfieation,  Jan  BO 
(d)  OoO  Olroetlva  4120*3#  *Oapartaant  of  Oafansa  Standardiaatioe 
Frograji,*  6  Juna  73 

(a)  OtoOZ  A120.20#  *^aval^ofia.1t  and  uaa  of  Boo-Oovamaant 
Spaa  if  loationa  and  Staadarda#*  2B  Oaa  7f 

1.  Tha  purpoaa  of  ma  aaoorandua  U  ta  alarlfy  OoO  paXiar  aeoeamiAg 
ataadardUatioa  of  baai*io«>boat  pratoaaXa  far  data  aaHBMOlaaUoaa  natworka# 

2*  Tha  poliay  aitad  la  rafa**aoaa  (a)  U  t*aaflV«ad#  aaaaXft  (1)  tba  uaa  of 
OoO  nandard  boat«ta-heai  pratoaaXa  (Tranaaissloo  ContraX  FratoaoX  (TCF)  and 
Xataraat  FrotoooX  (XF),  rafaranoaa  (b>  and  (a))  ia  aandatary  for  aXX  OoO 
paekat-oriantad  data  natiiertia  aOieli  bava  a  patantiaX  far  boat*to*lioat 
aonnaativlty  aaroaa  natvark  or  aubnataork  bouadarlaar  (2)  tim  Dlraator. 
Oafanaa  CoMunioationa  Afanay,  ia  daai^tad  aa  Um  IsaauUva  At«it  fv 
ooaputar  aoaauniaationa  prataaaXai  and  (3)  aaaa-by*aaaa  asaaptiona  viXX  ba 
crantad  by  tba  Cxaautioa  Afont  only  for  aataorka  abOMi  to  bara  no  flitura 
raauiraoanu  fop  iataroperabiXIty. 

3.  lafaranaa  (a)  ia  not  iatoNad  to  rapiaaa  tba  aormX  OuC  standardiaation 
proeaduraa  BatabXiabad  by  OaOO  4120.3  ;rafarar««a  (d)).  Batbar.  tba  Baaautlv* 
Afoat  funatiaa  ia  iataadai  U  lOaaa  4»8r«aaad  aapbaaia  and  UitUtiva  aa  tba 
ibportaat  aad  aurrantXy  vaUtiXa  taaboaXocy  •f  daU  aoMMiiaatiana  protaaaX 
atandarditation.  Maw  ataodarda  aad  aadifiaatiana  ta  aatatibg  ataodarda  wtXX 
ba  aobaittad  by  tha  Ciaautiva  Afoat  U  tba  Oafanaa  Oapartaant  aaapanaau  for 
ratification  and  diaaaainaUaa  ia  aaaardaaaa  with  tba  praaiaiana  of 
rafaranaa  (d). 

4.  DoOX  4120.20  (rafaraaoa  (a))  aJUa  aantlmiaa  to  apply  ta  pratoaaX 
atandarda.  tbna.  it  ia  daairad  that  nonfovamoant  protoaal  ataodarda  ba 
adoptad  and  uaad  ia  Uau  af  tba  dairaXopaant  and  probiiXaatiao  of  naa 
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THE  UNDER  SECRETARY  OF  DEFENSE 


WASHINGTON.  O  C.  MMI 


NCftAIKH  ANO 
KNOINCCNiNG 


KHAP  1963 


MaCRANDUH  PGR  SECRETARIES  OP  THE  MILITARY  0EPAR1MMS 
OIRBCTORS,  OEFBISE  MSaClfSS 
DIRECTOR,  JOIKT  STAFF,  OJCS 

SUBJECT:  Dofenss  DtU  Network  (DON)  I^>Ieatnution 


References:  (a)  Dep  Sec  Def  Hnorandw,  SiR>ject:  Termination  of 
AUlODIN  II,  2  April  1982 

(b)  OTAOCS  HMorandia,  Subject:  AIITODIN  II  Phase  I 
Decision  Paper  and  OSD  Guidance  for  Oau  Network 
Developments,  16  July  197S 


This  MBorandui  directs  the  iiDlmMntation  of  the  Defense  Dau  Network 
(DON)  in  accordance  with  Reference  (a).  This  namoranto  replaces  the  previous 
guidance  conuined  in  Reference  (b).  The  Director,  Defense  Conmaiications 
j^ency  (DCA)  is  overall  Progrtt  Muiager  for  DON. 

In  order  to  ensure  that  DON  is  implemented  as  an  operationally  and 
economically  effective  program,  the  following  areas  must  receive  expeditious 
and  comprehensive  attention: 

(1)  The  user  system  requirements  for  all  DoO  dau  communication  system 
must  be  confinud.  This  must  include  accurate  opemional  and 
technical  information. 

(2)  System  users  must  select  interfacing  methods  as  well  as  the 
timeframes  required  for  their  systems  to  connect  to  the  DON. 

(3)  An  effective  cost  recovery  scheme  which  provides  for  m^iuble  user 
service  costs  must  be  established. 

The  enclosure  hereto  contains  Guidance  and  Program  Direction  applicable 
to  DON  and  other  OoO  Data  Networks,  and  usking  in  sqpport  of  tha  Defense  Oau 
Network  Pre^am  (to  be  reviewed  by  DUSD  (C^I)  on  a  continuing  basis). 

In  order  to  assure  success  of  the  DON,  a  DON  Coordinating  Coa^ttee  has 
been  established,  chaired  by  the  Director  of  Information  Systems  with 
membership  from  the  OJCS,  Services,  and  appropriate  Defense  Agencies. 

Intensive  and  continuing  management  support  from  every  echelon  will  be 
rm^ired  to  make  this  viul  effort  a  success. 


Enclosure 
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GUIDANCE  AND  PROGRAM  DIRECTION  APPLICABLE  TO 
TOE  DEFENSE  DATA  NETWORK  AND  OTOER  DoD  DATA  NETOORKS 


References: 


(a)  Dep  Sec  Def  Meraorandun,  Subject:  Termination  of 
AUTODIN  II,  2  April  1982 

(b)  DTACCS,  Memorandum,  Subject:  AUTODIN  II  Phase  I  Decision 
Paper  and  OSD  Guidance  for  Data  Network  Developments, 

16  July  1975 

(c)  DUSD  (C^I)  Memorandun,  Subject:  Defense  Data  Network  -- 
Security  Architecture  Options,  10  May  1982 

(d)  Director  of  DCA  Memorandum,  Subject:  Defense  Data 
Network  --  Security  Architecture  Options,  19  Nov  1982 

(e)  Director  of  NSA  Memorandum,  Subject:  Defense  Data  Network, 
1  Nov  1982 


(f)  USDRE  Memorandun,  Subject:  DoD  Policy  on  Standardization 
of  Host-to-Host  Protocols  for  Data  Coninunications 
Networks,  23  March  1982 


I.  Applicability  of  Program  Guidance  and  Direction 

This  guidance  shall  be  applicable  to  the  Office  of  the  Secretary  of  Defense, 
the  J'>int  Chiefs  of  Staff,  Military  Departments,  and  Defense  Agencies,  The 
definition  and  scope  of  the  Defense  Data  Network  (DDN)  will  be  igniated  or 
refined  as  dictated  by  changes  in  user  requirements,  technological 
developments,  and  economic  factors.  Evolution  of  the  DDN  as  a  Defense 
Couinunications  System  (DCS)  element  will  be  governed  by  the  DCS  Five  Year  Plan 
(FYP)  process.  Any  major  changes  in  the  scope,  schedules,  cost,  or 
cemposition  of  the  network  must  be  reviewed  and  approved  by  DUSD  (C^I). 

II.  Definition  of  DDN 

DDN  is  a  data  coninunications  service  which  will  utilize  packet  technology  as 
its  primary  switching  technique  to  fulfill  the  data  coninunications  needs  of 
the  OoO.  The  DDN  is  the  data  comnuni cat ions  service  of  the  Defense 
CxMBunications  System  (DCS).  The  DDN  Program  Plan,  revised  19  May  1982,  and 
augmented  by  the  DDN  Security  Architecture  Reports,  (Ref  d  and  e)  provides  a 
coa|)rehensive  description  of  the  initial  planning  for  the  network. 

III.  Program  Strategy  for  Data  Networks 

The  DDN  will  supply  data  communications  services  in  support  of  critical 
military  operational  systems,  including  WWMCCS  and  intelligence  systems, 
general  purpose  .ADP  and  other  command  based  systems  and  data  net^^orks,  which 
have  requirements  for  long-haul  data  comnunication  services.  The  DDN  will 
provide  connectivity  for  these  subscriber  systems  with  the  goal  of  maximum 
potential  for  interoperability. 
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The  DDN  is  designed  to  incorporate  the  maximum  practical  modularity  and  flexi¬ 
bility  in  the  back^ne  system  and  its  various  interfaces  to  acconroodate 
significant  changes  in  user  requirements,  in  ADP  and  data  coninunications 
technology,  and  in  the  economic  factors  influencing  this  program.  Contractual 
and  implementation  planning  for  DDN  must  accommodate  variations  in  the  nunber 
of  switches  to  be  implemented  and  in  the  overall  implementation  schedule  of 
the  program.  Every  attempt  must  be  made  to  balance  this  flexibility  against 
reasonable  cost  impacts  to  the  backbone  system  and  the  individual  subscriber 
systems.  It  is  essential  that  DDN  planning  be  phased  in  a  cohesive  total 
program  implementation  that  is  operationally  and  economically  viable. 

DUSD  (C^I)  memorandum,  10  May  1982,  (Ref  c)  directed  DCA  and  NSA  to  conduct  a 
review  of  the  DDN  Security  Architecture  alternatives  for  the  integration  of 
the  various  subscriber  corinunities  that  comprise  the  DDN.  Refs  d  and  e 
describe  the  network  security  architectures  that  were  evaluated. 

The  approved  DDN  network  security  architecture  contains  two  segments,  a 
classified  segment  and  an  unclassified  segment.  The  two  segments  are 
connected  via  gates  which  allow  use  of  the  unclassified  segment  backbone  by 
the  classified  subscribers.  DDN  switches  in  the  classified  segment  (C^I 
network)  are  protected  to  the  SEC3lEr  level  and  military  encryption  devices  are 
enployed  on  all  classified  segment  trunk  and  access  lines.  All  subscribers  on 
the  classified  segment  are  connected  to  the  DDN  via  the  Internet  Private  Line 
Interface  (IPLI),  or  equivalent  end-to-end  encryption  (E^)  devices.  The 
unclassified  segment  (MILNET)  has  switches  in  restricted  locations  and  uses 
DES  trunk  encryption  in  CONUS,  and  has  switches  in  SECRET-cleared  facilities 
and  uses  military  encryption  devices  on  OCONUS  trunk  lines  and  on  OCONUS-CONUS 
connections.  The  software  in  the  packet  switches  and  monitoring  centers  will 
not  be  reinplemented,  but  will  be  examined  for  security  flaws  and  brought 
under  strict  configuration  control.  This  architecture  is  referred  to  in  the 
review  as  Option  2.2  --  WITH  (with  IPLIs  on  all  classified  hosts  and  without 
reimplementation  of  network  software.) 

Near-term  security  for  the  DDN  system  will  be  provided  through  link  encryption 
of  the  circuits  and  segregation  of  different  subscriber  corammities.  Pro¬ 
vision  of  DES  link  encryption  on  the  MILNET  shall  proceed  as  expeditiously  as 
possible,  but  inplementation  of  systems  shall  not  be  delayed  solely  because 
such  encryption  is  not  in  place.  Every  effort  must  be  made  to  exp^ite  the 
development  of  end-to-end  data  encryption  technology  via  the  Internet  Private 
Line  Interface  (IPLI)  and  BLACKER  Programs.  The  focus  of  these  efforts  should 
be  to  provide  host-to-host  encryption  protection.  The  BLACKER  effort  should 
provide  remote  key  distribution  and  a  trusted  (multilevel  secure)  E^  device 
suitable  for  use  on  the  DDN  by  programs  such  as  the  Inter-Service/Agency  AMPE, 
World-Wide  Military  Conmand  Control  Systems  (WWMCCS)  Information  Systems,  and 
SACDIN. 
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The  Director,  DCA  and  all  prospective  users  of  the  DDN  should  be  fully  aware 
of  the  requirements  of  the  Privacy  Act  of  1974,  should  monitor  all  follow-on 
guidance  deriving  from  this  Act  and  related  legislation,  and  should  plan  for 
all  appropriate  changes  to  the  design  or  operation  of  their  respective 
systems.  The  DDN  already  has  design  features  which  provide  for  ''command 
privacy*'  and  which  will  assist  in  minimizing  problems  from  the  perspective  of 
"personal  privacy." 

All  DoD  data  conmunication  systems  are  required  to  implement  the  DoD  Standard 
Host-to-Host  Transmission  Control  and  Internet  Protocols  CTCP/IP)  by  Ref  f. 
There  are  ongoing  concerted  efforts  within  the  government  and  industry  to 
develop  additional  standardized  data  communication  protocols.  These  efforts 
must  ^  monitored  closely  to  ensure  that  they  meet  the  functional  requirements 
of  the  DoD  and  whenever  possible  that  DoD  protocols  are  in  consonance  with 
these  efforts. 

At  the  present  time,  the  network  access  method  supported  by  the  DDN  is  the 
1822  interface  with  the  Transmission  Control  and  Internetwork  Protocols 
(TCP/IP).  Consistent  with  our  policy  of  using  commercial  interface  standards 
^enever  possible,  DCA  is  conducting  an  extensive  review  in  coordination  with 
the  National  Bureau  of  Standards  of  the  various  options  in  the  X25  network 
access  specification.  This  review  and  subsequent  testing  should  result  in  a 
specification  of  the  X2S  options  which  will  be  supported  by  the  DDN. 

Essential  characteristics  of  this  specification  will  be  efficient  operation 
with  TCP/IP,  with  existing  1822/TCP/IP  implementations  and  with  the  DDN 
end-to-end  encryption  capabilities.  The  wide  diversity  of  incompatible  X25 
implementations  presently  available  or  contemplated  in  the  commercial  market 
could  lead  to  serious  operational  problems  for  the  DDN  and  its  users.  Until 
the  DDN  X25  specification  has  been  approved  by  the  DoD  Protocol  Standards 
Steering  Group,  no  implementations  of  X25  will  be  authorized  for  use  on  the 
DDN. 
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IV.  Guidance  for  DoD  Data  Networks 
A.  Use  of  the  TON 

AH  DoO  ADP  ^sterns  and  data  networks  requiring  data  conmunications  services 
will  be  provided  long-haul  and  area  conmunications,  interconnectivity,  and  the 
capability  for  interoperability  by  the  DDN.  Existing  systems,  systems  being 
expanded  and  qpgraded,  and  new  ADP  systems  or  data  networks  will  become  DDN 
subscribers.  All  such  systems  must  be  registered  in  the  User  Requirements 
Data  Base  (URDB).  Once  registered  in  the  UkDB,  requests  bv  a  Service/ Agency 
for  an  exception  to  this  policy  shall  be  made  to  DUSD  (C3l).  Requests  for 
exceptions  for  joint  interest  systems  shall  be  routed  to  DUSD  (C^I)  through 
the  JCS.  Authorization  for  such  special  networks  may  be  granted  by  D(JSD  iCSl) 
on  the  basis  of  special  economic  or  operational  considerations  such  as: 

1.  The  nature  of  the  data  communications  services  required  cannot 
be  satisfied  by  DDN  or  a  reasonable  modification  thereto,  or 

2.  Critical  operational  requirements  necessitate  inroediate 
implementation  actions  to  provide  a  data  communications  service  earlier  than 
can  be  available  within  the  DDN  inplementation  schedule,  or 

3.  The  ADP  system  has  time-phased  requirements  for  conmunications 
support  which  can  be  satisfied  and  justified,  on  economic  grounds,  by  an 
interim  network  with  subsequent  transition  to  DDN  when  economically  feasible. 

The  DDN  Program  Manager  will,  based  on  the  latest  information  contained  in  the 
URDB,  prepare  projections  at  several  time  intervals  (e.g.,  6  months,  one  year, 
two  years)  of  the  future  topology  and  data  flow  characteristics  for  the 
networks  that  comprise  the  DDN.  These  projections  will  be  distributed  for 
comment  to  the  OJCS,  Services  and  i^encies.  Every  attempt  will  be  made  in 
these  topology  projections  to  provide  equivalent  or  better  service  to  all 
current  DDN  subscribers.  Services/Agencies  should  carefully  review  these 
projections  and  resolve  any  problems  with  the  DDN  Program  Manager.  Only  in 
case  of  irresolvable  problems  should  the  matter  be  brought  to  the  attention  of 
the  DDN  Coordinating  Conmittee. 

The  DDN  Program  Manager  will  provide  for  informal  electronic  mail  capabilities 
of  the  MILNET  similar  to  those  presently  on  the  ARPA  network.  Provisions  for 
funding  these  services  through  the  Conmunications  Services  Industrial  Fund 
(CSIF)  should  be  made  available  as  soon  as  possible. 

Users  are  encouraged  to  connect  general  purpose  ADP  resources  to  the  DDN  for 
the  purpose  of  sharing  computational  resources  with  others  of  the  network. 

This  provision  includes  the  connection  of  commercially  available  resources 
where  appropriate. 
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B.  Specific  Network  Guidance 

1.  ARPA  Network 

Those  Service/Agency  ADP  systems  that  are  currently  connected  to  the  ARPA 
network  or  for  which  ARPA  network  connection  is  planned  will  form  the  baseline 
for  the  unclassified  portion  of  DDN  which  has  been  designated  the  MILNET.  The 
ARPA  network  will  be  partitioned  into  the  MILNET  and  an  Experimental  Network 
as  quickly  as  possible.  Electronic  mail  forwarding  capabilities  will  be 
provided  between  the  two  networks.  Positive  network  access  control  measures 
will  be  irapleruented  on  the  MILNET  and,  once  fully  employed,  will  allow 
authorized  MILNET  user  full  internet  access  to  the  Experimental  Network  but 
prohibit  full  internet  access  to  MILNET  from  the  Experimental  Network. 

The  CONUS  switches  in  the  MILNET  will  be  located  on  restricted  access 
locations  and  use  the  DES  encryption  techniques  on  all  trunks.  OCONUS 
switches  will  be  located  in  SECRET  cleared  facilities  and  military  encryption 
devices  will  be  used  on  all  OCONUS  trunks  and  all  OCONUS-CONUS  connections. 

The  Experimental  Network  (which  will  retain  the  name  ARPANET  network)  will  be 
utilized  for  computer  network  research  and  to  test  concepts  to  be  enployed  in 
the  DDN.  The  Experimental  Network  will  be  managed  and  operated  by  the  DDN 
Program  Office.  Policies  governing  its  operation  will  be  established  by  a 
Steering  Connittee  composed  of  the  DON  Program  Manager  and  sponsors  of  systems 
using  the  Network.  The  Chairman  of  this  Steering  Committee  will  be  appointed 
by  the  Director  of  the  Defense  Advanced  Research  Projects  Agency. 

2.  WWMCCS  IntercoiT5)uter  Network 

The  comnunications  subsystem  of  the  WIN  is  the  basis  for  the  classified 
portion  of  the  DDN.  The  DDN  will  provide  service  to  the  WWMCCS  ADP  community 
under  the  direction  of  the  JCS  and  in  accordance  with  a  WIN-DDN  Transition 
Plan  to  be  developed  by  the  DDN  Program  Manager  and  the  JCS.  Department  of 
Defense  Intelligence  Information  Systems  and  other  classified  subscriber 
comnunities  will  be  added  to  the  WIN  communications  subsystem  to  form  the  C^I 
network  as  soon  as  end-to>end  encryption  tneasures  are  available. 

3.  Movements  Information  Network 

The  USEUQOM  Movements  Information  Network  (MINED  will  initially  be  managed  as 
a  separate  testbed  network  to  detemlne  if  urgent  transportation  requirements 
of  the  United  States  Military  in  Europe  can  be  satisfied  by  electronic  means. 
As  soon  as  the  MILNET  is  physically  partitioned  from  the  experimental  network, 
the  MINET  communications  subnetwork  will  become  an  Integral  part  of  the 
MILNET.  Additional  users  in  Europe  not  covered  in  the  original  MINET  planning 
documents  will  be  integrated  into  the  MILNET  communications  subnetwork  by  the 
DDN  Program  Manager  in  a  manner  not  to  degrade  service  to  the  MINET  testbed. 
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V.  Tasking  in  Stgport  of  the  Defense  Data  Network  Prograi 

A.  Tasking  for  the  Chairman,  Joint  Chiefs  of  Staff 

1.  Revision  of  various  MOPs  as  required  to  comply  with  the  guidance 
contained  herein,  and  publication  of  a  new  MDP  addressing  the  DDN. 

2.  Validate  joint- interest  user  system  requirements  and  forward  to 

DCA. 

B.  Tasking  for  the  Director,  Joint  Staff 

1.  The  Joint  Staff  should  monitor  the  general  progress  of  the 
tasks  identified  in  this  enclosure  and  assist  the  DCA,  Military  Departments, 
and  other  Defense  Agencies  as  appropriate. 

2.  The  Joint  Staff  should  continue  consideration  of  the  potential 
requirements  of  the  Unified  and  Specified  Conmands  which  might  logically 
relate  to  the  DDN  program.  This  would  include  the  appropriato  potential 
requirements  for  NATO  interfaces,  deployment  of  switches,  interfaces  to 
tactical  data  systems,  changes  in  the  level  of  survivability  needed,  and  other 
longer  range  data  conmunication  planning  issues. 

C.  Tasking  for  the  Director.  DCA 

1.  The  Director,  DCA  should  accomplish  the  following  tasks  and 
report  to  DUSD  (C^I)  as  necessary. 

(a)  Develop,  operate  and  manage  the  DDN  on  a  subscriber- to - 
subscriber  basis. 

(b)  Confirm  user  system  requirements  in  order  to  establish  arid 
maintain  a  data  base  of  data  conminications  requirements  for  system  planning 
and  sizii^.  This  action  should  include  both  updated  projections  based  on  the 
tasking  included  in  other  parts  of  this  enclosure  and  identification  of  the 
specific  timeframes  when  candidate  user  systems  can  be  connected  to  the  DDN. 

(c)  Develop  and  refine  a  reporting  format  which  will  allow  the 
Military  Departments  and  Defense  Agencies  to  provide  the  user  requirements 
data,  tasked  elsewhere  in  this  enclosure,  in  a  consistent  manner. 

(d)  Review  the  technical  concept  of  operation  for  each 
candidate  ADP  system  to  ensure  that  the  DON  can  adequately  support  these  ADP 
system  requirements. 

(e)  Coordinate  with  the  appropriate  agencies  to  ensure  that 
the  DON  specifications  properly  identify  and  fully  address  network  security 
and  privacy  requirements. 
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(f)  Provide  technical  review  and  validation  of  the  protocols, 
interfaces,  precedence,  and  security  features  of  the  DDN  and  the  ira^cts  on 
user  systems.  Ihis  validation  should  be  accomplished  through  experimentation, 
consultation  and  coordinaf.on  with  the  user  conmunities,  and  evaluation  by 
recognized  experts  from  government  and  industry. 

(g)  Develop  a  network  reporting  system  that  provides  clear 
management  visibility  on  network  operations  of  the  DDN. 

(h)  Develop  effective  cost  recovery  alternatives  for  the  DDN 
through  the  Connunications  Services  Industrial  Fund  (CSIF)  based  on  equitable 
rates  reflecting  actual  system  usage  to  the  maximun  extent  feasible. 

(i)  Establish  appropriate  management  thresholds  which  will 
ensure  early  identification  of  major  changes  or  problems  in  the  program  costs 
or  schedules. 

(j)  Investigate  the  potential  use  of  network  interfacing 
devices  which  will  minimize  subscriber  conversion  and  operational  impacts. 

(k)  Assist  the  Military  Departments  and  Defense  Agencies  in 
accomplishing  their  designated  tasks. 
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Dc  Tasking  for  the  Military  Departments  and  Defense  Agencies 

1.  Develop  and  forward  in  a  timely  manner  the  required  information 
on  all  'urrently  operational  and  planned  ADP  systems  and  data  networks  that 
require  long-haul  and  area  data  communications  support.  This  information 
should  be  revised  as  necessary  to  keep  the  User  Requirements  Data  Base  as 
accurate  as  possible. 

2.  Plan  and  program  to  assist  the  Director,  DCA  in  the 
implementation  of  the  DDN  and  user  systems. 

3.  Reassess  current  concepts  of  operations  and  reporting 
instructions  in  light  of  the  features  and  capabilities  available  through  the 
use  of  the  DDN,  and  plan  for  possible  improvements. 

4.  Carefully  assess  the  security  features  of  the  DDN  and  determine 
how  to  maximize  their  security  protection.  Although  these  security  features 
may  be  helpful  for  ADP  system  operations,  they  do  not  solve  the  multilevel 
security  problems  of  the  ADP  systems. 

5.  MILDEPs  and  Agencies  are  responsible  for  interfacing  their  data 
communications  systems  to  the  DDN  in  accordance  with  DDN  interfacing  specifi¬ 
cation.  Where  mutually  agreed  by  MILDEPs/ Agencies  and  DCA,  DCA  will 
coordinate  and  manage  the  development  of  families  of  network  interfaces. 


Assist  the  Director,  DCA  in  ensuring  the  security  integrity  of  the  conmuni- 
cations  systems,  including  segregration  of  GENSER-SI  traffic,  segregation  of 
subscriber  coontunities.  Defense  Switched  Network  (AUTOVON)  dial-up  circuit 
protection  procedures,  overall  network  security,  and  other  appropriate  areas 
of  security. 
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THE  UNDER  SECRETARY  OF  DEFENSE 

W/\!»H»NCrON  OC  20JOI 

MAy  iiM 

rascAncH  ANO 
CNCiNCCfflNC 

(C3l) 

MBORANOUN  FOR  SECRETARIES  Of  IHE  MILITARY  0EPAR1MEN1S 
DIRECTORS  OF  THE  DEFENSE  AGENCIES 
DIRECTOR,  JOINT  STAFF,  OJCS 

SUBJECT:  OoD  Policy  on  Defense  Data  Network  (DON)  Protocols 


Under  Secretary  of  Defense  (Research  and  Engineering)  Memorandun  "Defense 
Data  Network  (DON)  Inplenentatian,"  dated  10  March  X9&3  prohibited  the  use  of 
X.2S  connections  to  the  DON  until  the  DON  X.2S  specification  had  been  approved 
by  the  OoD  Protocol  Standards  Steering  Group  (PSSG).  The  DDN  X.2S  specifi¬ 
cation  has  been  approved  by  the  PSSG  and  it  is  hereby  authorized  for  use  on 
the  DON. 


The  requirement  to  use  the  OoD  Standard  Host-to-Host  Transmission  Control 
and  Internet  Protocols  (TCP/IP)  promulgated  by  USORB  Memorandtin,  "DoO  Policy 
on  Standardization  of  Host-to-Host  Protocols  for  Data  Connunicatims 
Networks,"  23  March  1982,  remains  in  effect. 

With  the  approval  of  the  DON  X.25  specification  in  the  Defense 
Communications  Agency  (P8SI)  Memorandui,  "DON  X.25  Specification,"  4  January 
1984,  the  OoD  has  taken  another  step  toward  standardized  data  communication 
protocols,  along  with  industry  and  the  international  cosmunity.  Since  the  use 
and  availability  of  the  X.2S  protocol  is  widespread,  every  effort  should  be 
made  to  bring  DoO  in  line  with  all  the  data  communications  users  in  this  area. 
The  DON  X.2S  will  be  used  as  the  access  protocol;  TCP  and  IP  will  continue  to 
be  used  in  the  internet  and  transport  layers.  The  1822  protocol  will  continue 
to  be  supported  by  the  DON  until  phased  out  via  evolution. 


All  new  systems  and  systems  undergoing  major  redesign  are  required  to  use 
levels  2  and  3  of  the  DON  standard  X.2S  protocol  for  interfacing  to  the  DON. 
Case-by-case  waivers  will  be  considered  by  Assistant  Secretary  of  Defense 
(C^I).  The  on-going  I-S/A  AMPE  and  BLACKER  programs  are  specifically 
requested  to  take  steps  to  implement  the  DDN  Standard  X.2S  specification  as 
early  as  possible. 


f!  DU. 


iu 


CONFIGURATION  MANAGEMENT 


ASSISTANT  SECRETARY  OF  DEFENSE 
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DirTRlPUTlOI*' 
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MMOtANDM  FOR  OIRBCTGR.  DiffBlSE  OOMUNICATIGNS  MBCY 

SnjECT:  National  Research  CotiKil  Report  «i  Transport  Protocols  for  Dai> 

Data  Networks  ~ 


CCA 


/.fl'on 

FO 


Attached  it  the  final  report  on  *Tran$port  Protocols  for  Departaent  !of  • 
Defense  Data  Netwrks**  fron  the  Kstional  Research  Council  (Boardm 
m^OBmications  and  Ossputer  Applications,  Conission  on  Bnginetrins  and 
Taclnicai  Systw).  lha  report  reconends  that  D6D  iMediataly  adoM  the 

Standards  Orgsnizstion  Transport  Protocol  (TP-4)  andtotamatNork 
Protocol  (IP)  as  a  M  co-standard  to  ths  currant  DoS  standard  ITvialt^ 
Control  Protocol  (TCP)  and  IP  and  nova  ultinataly  tOMird  exclwtva  uso  of  TP-4. 

Mianavar  intamational  standards  are  arallaUe  and  can  be  used  to  Mmort 
nlllury  requlrMnu.  they  will  be  iiBlsMnted  as  rapidly  u  possible  to^in 
interoperabilltybeneflts.  Howem/lP  aiTo  proven 
ooMrcial  offerl^  la  not  availabla  at  this  tins,  lha  protress  of  TP  will  bt 
nonltorod  carefully  and  once  coMarclally  available,  TP  will  be  tested  and 
evaluated  for  use  in  nllitary  applications. 


"A" 

4I|M 


In  or*r  to  insure  ^t  DoD  is  in  a  posture  to  evaluate  TP  once  It  is  In 
wider  use  in  the  ctantrcial  sector,  re^t  you  Initiate  the  followini  Ktlora: 


(1) 

(2) 

(3) 

(4) 

(5) 


^  DoO  nlliury  rei)uir«Mnt  qiecification  for  TP  to 
pisuro  that  inAiatry  is  SMere  OoO  noads  as  TP  is  ceaaerclally 


insure  that  mproprlate  advisory  represenution  is  providod  to 
MKssKiti  standards  wrkini  froivs  that  are  oirrantly  raflnlM 
TP  iBidar  tha  auspices  of  ths  Naticnal  Bureau  of  Standards. 


insure  that  ths  CCA  protocol  test  facility  can  accoasodate  TP 
teatini  as  raqulred  idwn  caaasrciai  taplananutlens  art  available. 

develop  a  transition  strsteiy  for  Option  2  of  tha  rmort  to  iixluds 
astlnatod  resource  recjuiraasnts. 


reco^endstlons  presented  in  the  Beport 
(pages  41-64)  at  they  ipply  to  Option  2.  aid  tfithiar* 


Donald  C.  Lathaa 


i:-.)  to  toi'.AkZ.  <« 
ic.na  ta*  t^.r?ia'J 


cc:  MBS,  Mr.  Bob  Blanc 
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4.3  Protocol  Testing  mnd  Validetlon  (IW&T) 

Protocol  testing  of  vendor  products  end  host  Implementations  are  carried  out  by  DCA 
Code  B613|  the  Development  Test  and  Evaluation  Branch  of  the  DDN  PMO.  Vendors 
wishing  to  have  products  validated  should  contact  thb  branch  for  Information. 

Emphasb  of  this  group  to  date  has  been  on  testing  backbone  equipment  and  software. 
Test  procedures  are  being  developed  to  assist  site  personnel  with  testing  and  validating 
Implementations  of  the  DoD  Internet  protocols  on  their  local  hosts.  Announcements  will 
be  made  via  the  DDN  Management  Bulletins  or  Newsletters  as  new  testing  tools  and 
procedures  become  available. 

4.4  Announcemant  Procedures 

Official  ME.  STD  protocols  are  deposited  at  the  Naval  Publications  and  Forms  Center 
and  are  announced  In  the  catalogs  published  by  that  organisation. 

Each  branch  of  the  military  has  its  own  protocol  announcement  procedure  as  do  non* 
military  government  agencies,  such  as  the  National  Bureau  of  Standards.  Commercial, 
national,  and  international  standards  organisations  also  have  their  own  review  and 
announcement  procedures.  It  is  be3rond  the  scope  of  this  book  to  summarise  each  of 
these  procedures.  (See  IEEE  Ccmmunications  Mogoiine,  Vol.  23,  No.  I  (Jan.  1086) 
for  an  excellent  overview  of  the  standardisation  practices  of  the  various  protocol 
standardisation  bodies.] 

4.4.1  Requests  for  Comments  (RFCs) 

Requests  for  Comments  (RFCs)  are  technical  notes  describing  protocol  development  and 
related  topics  of  interest  to  the  ARPANET  and  DDN  research  community.  Proposed 
protocola  or  discussions  of  protocols  while  they  are  under  development  are  found  in  the 
RFCs;  therefore,  this  is  an  important  set  of  documents  to  monitor  if  you  wbh  to 
influence  the  de^gn  of  a  protocol  before  it  is  adopted  as  a  standard,  or  if  you  wish  to 
track  the  progress  of  DARPA  experimental  protocols. 

The  RFCb  are  maintained  online  by  the  NIC  on  behalf  of  DARPA  and  the  DDN  PMO. 
Dr.  Jonathan  B.  Postel  currently  serves  as  £ditor>in-Chief  of  the  RFCs.  Researchers 
wishing  to  submit  an  RFC  for  publication  should  se/id  It  online  to 
POSTELOUSC-ISIFARPA.  The  document  format  for  RFCs  should  folbw  the 
standards  outlined  in  the  Instneiions  for  Aulhort  of  RFCs,  available  online  at  the 
NIC  in  the  Hie  RFCAUTH0R-INSTRUCT.TXT.  Section  5.3  explains  how  to  obtain 
copies  of  the  RFCs  and  how  to  be  added  to  the  online  distribution  list  for 
announcements. 
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4.4.2  DCA  Cireul&rs 

Information  of  particular  importance  to  military  users  is  often  published  as  a  DCA 
Circular.  DCA  Circulars  are  available  in  hardcopy  from  the  Defense  Technical 
Information  Center  (DTIC). 

4.4.3  DDN  MAnagemont  Bullotina  and  Newsletters 

The  DDN  PMO  uses  online  DDN  Management  Bulletins  and  informal  newsletters  to 
announce  the  acceptance  of  new  protocob  and  to  inform  site  personnel*  members  of  the 
Communications  and  Operations  Group  (COG)  and  implementors*  of  actions  to  be 
taken  or  decbions  made  with  respect  to  protocol  adoption*  change*  enhancement*  or 
deletion.  The  Management  Bulletins  are  dbtributed  by  the  DDN  Network  Information 
Center  (NIC)  on  behalf  of  the  DDN  PMO.  DDN  users  wishing  to  receive  the  DDN 
Management  Bulletins  online  may  send  an  electronic  message  to  NICQSRI-NIC.ARPA 
or  call  the  NIC  telephone  ** hotline”  on  (800)  235-3155,  and  ask  to  be  added  to  the 
distribution  list.  Implementors  who  are  government  contractors  may  also  obtain  copies 
of  DDN  Management  Bulletins  from  their  contract  monitors. 

4.4.4  The  TACNEWS  Service 

TACNEWS  b  a  network  service  provided  by  the  NIC  which  permits  users  to  quickly 
and  easily  check  for  announcements*  or  read  the  DDN  Management  Bulletins  and 
Newsletters.  It  can  be  accesMd  from  a  Terminal  Access  Controller  (TAG)  or  from 
another  host. 

To  access  TACNEWS  from  a  TAC,  log  in  and  type: 

OB<Rtutra> 

Uciitwf  <  RHura  > 

To  access  TACNEWS  from  another  DDN  or  ARPANET  host,  make  a  TELNET 
connection  from  that  host  to  the  SRI-NIC  machine  as  follows: 

ulaei<R«itsfii> 
coQiMct  $RI-NlC<RHura> 

To  access  TACNEWS  once  the  TELNET  connection  b  compleud,  type: 


<  Rh  am  > 
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SECTION  5.  OBTAINING  PROTOCOL  INFORMATION 

5.1  Military  Standards 

MIL  STD  protocols  can  be  ordered  from: 

Naval  Publications  and  Forms  Center,  Code  3015 
5801  Tabor  Drive 
Philadelphia,  PA  19120 
Telephone:  (215)  697-3321 

5.2  The  DDN  Protocol  Handbook 

Additional  copies  of  this  1985  DDN  Protocol  Handbook  can  be  ordered  from: 

DDN  Network  Information  Center 
SRI  International,  Room  EJ291 
333  Ravenswood  Avenue 
Menlo  Park,  CA  94025 
Telephone:  (800)  235-3155 

The  price  for  the  three- volume  set  is  $110.00,  prepaid,  to  cover  the  cost  of  reproduction 
and  handling.  Checks  should  be  made  payable  to  SRI  International.  Copies  of  the 
handbook  will  also  be  deposited  at  DTIC. 

5.3  Requests  for  Comments  (RFCs) 

RFCs  arc  available  online  or  in  hardcopy  from  the  NIC.  For  network  users,  the  online 
versions  can  be  obtained  via  FTP  from  the  SRI-NIC  host  computer  (26.0.0.7S  on 
MILNET  and  10.0.0.51  on  ARPANET)  using  username  "anonymous"  and  password 
"guest"  and  the  pathname  of  RFC:RFCxxx.TXT,  where  "xxx"  equals  the  number  of 
the  RFC  desired.  An  online  index  is  also  available  with  pathname 
RFC:RFC-INDEX.TXT.  Individuals  who  wish  to  be  added  to  the  RFC  notification  iist 
should  send  a  message  to  NIC@SRI-NIC.ARPA  requesting  that  their  names  be  added  to 
the  online  distribution  list.  Hardcopies  of  RFCs  may  be  obtained  from  the  DDN 
Network  Information  Center  by  sending  a  check  or  purchase  order  made  payable  to  SRI 
International  in  the  amount  of  $5.00  for  each  copy  under  100  pages,  or  $10.00  for  100 
pages  and  above. 

5.4  DDN  Management  Bulletins  and  Newsletters 

The  DDN  Management  Bulletins  and  informal  DDN  Newsletters  are  available  for  FTP 
from  the  SRI-NIC  machine  using  username  "anonymous"  and  password  "guest"  and 
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pathnames  of  the  type  DDN-NEWS:DDN-MGT-BULLETIN-xx.TXT  and 
DDN- NEWS :DDN-NEWS-xx. TXT,  where  ’’xx'*  is  the  number  of  the  bulletin  or 
newsletter  desired.  All  of  the  newsletters  that  are  still  current  are  online  on  the  NIC 
machine. 

Special  quarterly  issues  of  the  DDN  Newsletter  are  published  both  online  and  in 
hardcopy.  The  hardcopy  versions  are  distributed  to  appropriate  military  agencies  by 
the  DDN  PMO.  Additional  copies  are  available  from  the  NIC. 

Both  DDN  Management  Bulletins  and  DDN  Newsletters  can  also  be  read  using  the 
TACNEWS  service  described  above. 

5.5  NIC  Services 

The  DDN  Network  Information  Center  (NIC)  assists  users  in  obtaining  information 
pertaining  to  DoD  protocols.  The  NIC  publishes  the  DDN  Protocol  Handbook  and 
maintains  a  NIC  Repository  of  DoD  and  related  protocol  documents.  It  houses  the 
DDN  Management  Bulletins,  the  DDN  Newsletters,  the  Requests  for  Comments  (RFC) 
technical  note  series,  and  also  produces  the  TCP/IP  Protocol  Implementation  and 
Vendors  Guide,  The  NIC  is  a  good  place  to  start  if  you  need  information. 


(800)  235-3155 

is  the  toll-free  telephone  number  to  call  for  user  assistance.  Service  is  available  Monday 
through  Friday,  7  am  to  4  pm.  Pacific  time. 

The  NIC  host  computer  is  a  DEC- 2065  running  the  TOPS- 20  operating  system  with  the 
hostname  SRI-NIC  and  host  addresses,  26.0.0.73  (MILNET)  and  10.0.0.51  (ARPANET). 
NIC  online  services  are  available  24  hours  a  day,  7  days  a  week.  Operations  personnel 
are  in  attendance  from  4  am  -  11  pm  weekdays,  and  8  am  -  12  pm  weekends.  Pacific 
time. 

Send  online  mail  to: 

NIC(aSRI-NIC.ARPA 

Send  U.S.  mail  to: 

DDN  Network  Information  Center 
SRI  International,  Room  RJ201 
333  Ravenswood  Avenue 
Menlo  Park,  CA  94025 


•-  N  ' 
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5.6  Other  Information  Sources 

A  subscription  to  the  DoD  Index  of  Specifications  and  Standards  (DODISS)  can  be 
ordered  from: 

Naval  Publications  and  Printing  Service  Office 
Fourth  Naval  District 
700  Robbins  Avenue 
Philadelphia,  PA  19111 

FIPS  Standards  can  be  ordered  from: 

National  Technical  Information  Service  (NTIS) 

U.S.  Dept,  of  Commerce 
5285  Port  Royal  Road 
Springfield,  VA  22161 
Telephone:  (703)  487-4630 

ANSI  Standards  can  be  ordered  from: 

American  National  Standards  Institute  (ANSI) 

Sales  Department 
1430  Broadway 
New  York,  NY  10018 
Telephone:  (212)  354-3300 

IEEE  documents  are  available  from: 

Institution  of  Electrical  and  Electronic  Engineers 
445  Hoes  Lane 
Piscataway,  NJ  08854 

CCITT  documents  can  be  ordered  from: 

International  Telecommunications  Union 
General  Secretariat,  Sales  Section 
Place  des  Nations 
CH-1211  Geneva  20 
SWITZERLAND 


vv 
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SECTION  6.  DOD  MILITARY  STANDARD  PROTOCOLS 

This  section  contains  the  official  DoD  Military  Standard  Protocols.  The  X,25  Protocol, 
Host  Front  End  Protocol,  and  the  Internet  Control  Message  Protocol  are  also  included 
but  are  currently  under  review. 
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This  docoMiit  spsdflss  ths  let^mst  Protocol  (I?)  which  supports  ths  Inter- 
coonsetlon  of  conmnlcstlon  suhnstirorks*  Ths  tlccuasot  includes  sn  Inttoduc- 
tion  to  IP  with  s  wcdel  of  operation*  s  definition  of  services  provided  to 
users*  end  s  description  of  the  srdutectursl  end  environaentsl  requlrewents* 
The  protocol  services  Intecfsces  and  aedbenlsM  ere  specified  using  sn  sbstrset 
state  wachlfie  aodel* 
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Vhartjdaat  -  --  --  --  --  --  --  --  - 
tfhara*to  -  --  --  --  --  --  —  -  --  - 
DadLaloa  table  action  proeaduraa  -  -  -  -  - 
Analyte-*  -  --  --  --  --  --  --  --  -- 

lulldAaeod  - 

Cospttte^checkaun  -  --  --  --  --  --  -- 
Cenpute^lcnp^checkaun  -  --  --  --  --  - 
Irror^to’  aoifee-*  -  --  --  --  --  --  -- 
irrorjtoYnJP  -  --  --  --  --  --  --  -- 
PragiMatTaead-  -  --  --  --  --  --  --  - 
Localjdellveiy  -  --  --  --  --  --  --  - 
teaaaMfely  -  --  --  --  --  --  --  --  - 
Eeaaaenbled^de  lively  -  --  --  --  --  -- 
leaaaenblyjtleeont  -  --  --  --  --  --  - 
teBotejdeUvety*  -  --  --  --  --  --  -- 
toute*”  -  --  --------------- 


EXECUTION  INVliOltairT  IXqUZUKEirrS 
Deecrlptloo*  -  --  --  --  --  - 
Inteiprecaee  eonnunlcatlon  -  -  - 
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1.  SCOPE 

U1  Purposs.  This  stsndsrd  establishes  criteria  for  the  Internet  Protocol 
(IP)  which  supports  the  Interconnection  of  conaunlcatlon  subnetworks o 

1.2  Organlfmtlon«  This  staniard  Introduces  the  Internet  Protocol's  role 
and  purpose,  defines  the  services  provided  to  users,  and  specifies  the 
■tchanlsw  needed  to  support  those  services*  This  standard  also  defines  the 
services  required  of  the  lower  protocol  layer,  describes  the  upper  and  lower 
Interfaces,  and  outlines  the  execution  envlronoent  services  needed  for 
lapleasntatlon. 

1.3  Application.  The  Internet  Protocol  (IP)  and  the  Transnlsslon  Control 
Protocol  (TCP)  are  aandatoiy  for  use  In  all  DoD  packet  switching  networks 
which  connect  or  have  the  potential  for  utilising  connectivity  across  network 
or  subnetwork  boundaries.  Network  elensnts  (hosts,  front-ends,  bus  Interface 
units,  gateways,  etc.)  within  such  networks  which  are  to  be  used  for  Inter¬ 
netting  shall  InplsMnt  TCP/IP.  The  tern  network  as  used  herein  Includes 
Local  Area  Networks  (LANs)  but  not  Integrated  weapons  systems.  Use  of  TCP/IP 
within  LANs  Is  strongly  encouraged  particularly  where  a  need  Is  perceived  fur 
equlpasnt  Interchangeability  or  network  survivability.  Use  of  TCP/IP  In 
weapot.'s  aystens  Is  also  encouraged  where  such  usags  does  not  dlniulsh  network 
perforaanoa. 
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2.  REFERENCED  DOCUMENTS 


2*1  Issues  of  documents.  The  following  docunents  of  the  issue  in  effect 
on  date  of  invitation  for  bids  or  request  for  proposal,  font  a  part  of  this 
standard  to  the  extent  specified  herein.  (The  provisions  of  this  paragraph 
are  under  consideration.) 

2.2  Other  publications.  The  following  docuaents  fora  a  part  of  this 
standard  to  the  extent  specified  herein.  Unless  otherwise  indicated,  the 
issue  in  effect  on  date  of  invitation  for  bids  or  request  for  proposes  shall 
apply.  (The  provisions  of  this  paragraph  are  under  consideration.) 
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3.  DEFINITIONS 

3.1  Definition  of  terns.  The  definition  of  tens  used  in  this  ttenderd _ 

shall  coSSIy  nith  PED^STO^1037.  Terns  and  definitions  unique  to  MIL-STD-1777 
era  contained  herein. 

a.  Datagran.  A  self-contained  package  of  data  carrying  enough  infoma- 
t ion  to  be  routed  fron  source  to  destination  without  reliance  on 
earlier  ezchangei^  bedreen  source  or  destination  and  the  transporting 
subnetwork. 

b.  Dataaran  fragnent.  The  result  of  fragnenting  a  datagran,  also 
sinply  referred  to  as  a  fragnent.  A  datagran  fragnsnt  carries  a 
portion  of  data  fron  the  larger  original,  and  a  copy  of  the  origi¬ 
nal  datagran  header.  The  header  fragnentation  fields  are  adjusted 
to  iiriicate  the  fragnent ’s  relative  position  within  the  original 
datagran. 

c.  Datagran  service.  A  datagran,  defined  above,  delivered  in  such  a 
way  that  the  receiver  can  detemlne  the  boundaries  of  the  datagran 
as  it  was  entered  by  the  eource.  A  datagran  is  delivered  with 
nott-sero  probability  to  the  desired  destination.  Tha  sequence 

in  which  datagrans  are  entered  into  the  subnetwork  by  a  source  is 
not  necessarily  preserved  upon  delivery  at  the  destination. 

<*•  P^etlnation.  An  IP  header  field  containing  an  internet  address 
Tndicating  where  a  datagran  Is  to  be  sent. 

e.  DF.  Don't  Pregnant  flag:  An  IP  header  field  that  when  set  •true" 
prohibits  an  IP  «>dule  fron  frajr^nting  a  datagran  to  acconplish 
delivery. 

f.  EFTP.  Electronic  File  Trans ff«r  Protocol.  Electronic  nail. 

E*  Fragnentation.  The  process  of  breaking  the  data  within  a  data¬ 
gran  into  snaller  pieces  and  attaching  new  internet  headers  to 
fom  snaller  datagrans. 

^  Fragnsnt  Offset.  A  field  in  the  IP  header  narking  the  relative 
posl^on  of  a  datagran  fragnent  within  the  largsr  original 

datagran. 

1.  FT?.  File  Transfer  Protocol. 

j,  Cateway.  A  device,  or  pair  of  devices,  which  Interconnect  two  or 
nore  subnetworks  enabling  the  passags  of  data  fron  one  subnetwork 
to  another.  In  this  architecture,  a  gateway  usually  contains  an 
IP  nodule,  a  Cat  away- toCat  away  Protocol  (CCP)  nodule,  and  a  sub¬ 
network  protocol  nodule  (SNP)  for  each  connected  subnetwork. 
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Collection  of  control  inforaation  transmitted  with  data 
between  peer  entitles* 

^  computer  which  Is  a  source  or  destination  of  messages 
from  the  point  of  view  of  the  communication  subnetwork. 

ICMP  *  Internet  Control  Message  Protocol,  the  collection  of  error 
conditions  and  error  message  formats  exchanged  by  IP  modules  In 
both  hosts  and  gateways* 

n*  Identification*  An  IP  header  field  used  In  reassembling  fragments 
of  a  datagram* 

o*  m*  Internet  Header  Length:  an  IP  header  field  Indicating  the 
oimber  of  32-blt  words  making  up  the  Internet  header* 

P*  Internet  address*  A  four  octet  (32  bit)  source  or  destination 
address  composed  of  a  Network  field  and  a  REST  field*  The  latter 
usually  contains  a  local  subnetwork  address* 

q.  Internet  datagram.  The  package  exchanged  between  a  pair  of  IP 
modules*  It  Is  made  up  of  an  IP  header  and  a  data  portion* 

l*ocal  address*  The  address  of  a  host  within  a  subnetwork.  The 
actual  mapping  of  an  Internet  address  onto  local  subnetwork 
addresses  Is  qiilte  general,  allowing  for  many  to  one  mappings* 

••  Local  subnetwork*  The  subnetwork  directly  attached  to  test  or 
gateway* 

t*  Jff*  More  Fragments  flag:  an  IP  header  field  indicating  whether  a 
datagram  fragment  contains  the  end  of  a  datagram* 

Maximum  Transmission  Unit:  a  subnetwork  dependent  value 
which  Indicates  the  largest  datagram  that  a  subnetwork  can  handle* 

v*  Octet*  An  eXght-blt  byte* 

Options*  The  optional  set  of  fields  at  Che  end  of  the  IP  header 
used  to  carry  control  or  routing  data.  An  Options  field  may 
contain  none,  one,  or  several  options,  and  each  option  may  be  one 
to  several  octets  in  length.  The  options  allow  ULPs  to  customise 
IP's  services.  The  options  are  also  useful  In  testing  situations 
to  carry  diagnostic  data  such  as  timestamps. 

X.  Packet  network.  A  netwoxk  based  on  packet->swltchlt^  technology* 
Messages  are  split  Into  small  units  (packets)  to  be  routed  Indepen* 
dently  on  a  store  and  forward  basis.  Thla  approach  plpellnaa 
packet  transmlselon  to  effectively  uee  circuit  bendwldth* 
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Padding.  An  IP  header  field,  one  octet  In  length,  Inserted  after 
the  last  option  field  to  eMure  that  the  data  portion  of  a  datagram 
begins  on  a  32-blt  word  boundary.  The  Padding  field  value  is  sero. 

*•  Internet  header  field  used  to  Identify  the  upper 

Xiyerprotocol  that  Is  the  source  and  destination  of  the  data 
within  an  IP  datagram. 

aa.  Reassembly.  The  process  of  piecing  together  datagram  fragments 
to  reproduce  the  original  large  datagram.  Reassembly  Is  based  on 
fragmentation  data  carried  In  their  IP  headers. 

>^Il*blllty.  One  of  the  service  quality  parameters  provided  by 
the  type  of  service  mechanism.  The  reliability  parameter  can  be 
set  to  one  of  four  levelst  lowest,  lower,  higher,  or  highest.  It 
appears  as  a  two-bit  field  within  the  Type  of  Service  field  In 
the  IP  header. 

ec.  Rest.  The  three-octet  field  of  the  Internet  address  usually 
containing  a  local  address. 

dd.  Segment.  The  unit  of  data  exchanged  by  TCP  modules.  This  term 
nay  also  be  used  to  describe  the  unit  of  exchange  between  any 
transport  protocol  modules. 

ee.  Source*  An  IP  header  field  containing  the  Internet  address  of 
the  ^tagram*s  point  of  origin. 

ff.  Stream  delivery  service.  The  special  handling  required  for  a 
class  of  volatile  periodic  traffic  typified  by  voice.  The  class 
requires  the  maximum  acceptable  delay  to  be  only  slightly  larger 
than  the  minimum  propagitlon  time,  or  requires  the  allowable 
variance  la  packet  Interarrlval  time  to  be  small. 

gg.  SUP.  Subnetwork  Protocol:  the  protocol  residing  In  the  euboecwork 
Tiyer  below  IP  which  provides  data  transfer  through  the  local  sub¬ 
net.  In  some  systems,  an  adaptor  module  must  be  inserted  between 
IP  and  the  eubnetwock  protocol  to  reconcile  their  dlselmllar 
Interfacee. 

hh.  TCP.  Trawmlsslon  Control  Protocol:  a  transport  protocol  providing 
connection-oriented,  end-to-end  reliable  data  transmission  in 
packet-switched  computer  subnetworks  and  intemetworke. 

TO  sepent.  The  unit  of  data  exchanged  between  TO  modules 
(including  the  TCP  header). 

JI*  Total  Ungth.  An  IP  header  field  containing  the  number  of  octets 
in  an  internet  datagram,  including  both  the  IP  header  and  the  data 
portion. 
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kk.  Type  of  Scrvlcs.  An  IP  header  field  containing  the  tranaaieaion 
quality  paraaetere:  precedence  level,  reliability  level,  speed 
level,  resource  trade-off  (precedence  vs.  reliability),  and  trans- 
mission  node  (datagraai  vs.  stream).  This  field  is  used  by  the 
type  of  service  mechanism  which  allows  Ulfs  to  select  the  quality 
of  transmission  for  a  datagram  through  the  internet. 

11.  UDP.  User  Datagram  Protocol. 

mm.  ULP.  Upper  Layer  Protocol:  any  protocol  above  IP  In  the  layered 
protocol  hierarchy  that  uses  IP.  This  term  includes  transport 
layer  protocols,  presentation  layer  protocols,  session  layer 
protocols,  and  application  programs. 


nn.  Varsion.  An  IP  header  field  indicating  the  format  of  the  IP 
hea^r. 
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4.  GENERAL  REQUIREMENTS 

4*1  D#glgn»  The  lattrngt  Protocol  is  designed  to  interconnect  packet- 
switched  coMunicstion  subnetworks  to  fom  sn  internetwork.  The  IP  trsns- 
aits  blocks  of  dsts,  celled  internet  dstegreas,  frea  sources  to  destinstions 
throughout  the  internets  Sources  end  destinstions  ere  hosts  located  on 
either  the  seas  subnetwork  or  connected  subnetworks.  The  IP  is  purposely 
liaited  in  scope  to  provide  the  basic  functions  necessary  to  deliver  a  block 
of  data.  Each  internet  datagraa  is  an  independent  entity  unrelated  to  any 
other  internet  dstagrsa.  The  IP  does  not  create  connections  or  logical 
circuits  and  has  no  aschanisas  to  prcaote  data  reliability,  flow  control, 
sequencing,  or  other  services  coaaonly  found  in  virtual  circuit  protocols. 

4.2  Internet  protocol  definition.  This  standaid  specifies  a  host  IP. 

As  definea  In  tM  Dob  architectural  aodel,  the  Internet  Protocol  resides  in 
the  internetwork  layer.  Thus,  the  IP  provides  services  to  transport  layer 
protocols  and  relies  on  the  services  of  the  lower  network  layer  protocol 
(See  figure  I).  In  each  gateway  (a  systea  interconnecting  two  or  aore  subr- 
nets)  an  IP  resides  about  two  or  aore  subnetwork  protocol  entities.  Gateways 
iopleasnt  internet  protocol  to  forward  datagraas  between  networks.  Gateways 
also  iapleasnt  the  Gateway  to  Gatew^r  Protocol  (GGP)  to  coordinate  routing 
and  other  internet  control  Inforaation. 


FIGURE  1.  Easaple  host  protocol  hierarcoy. 

4.2.1  Protocol  lapleaentation.  In  a  gateway  the  higher  level  protocols 
need  not  be  iapleaented  an^  GGP  functions  are  added  to  the  IP  nodule 
(See  figure  2). 
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ASPANET  LOCAL  NET  SUSLIC  NET 


FIGURE  2.  Exwplf  gatgwsy  protocol  hlTTchy* 

4.2.2  Upper  liycr  protocol.  A  protocol  in  an  upper  layer  pastas  data  to 
IP  for  delivery.  IP  packages  the  data  as  an  Internet  datagraa  and  passes  It 
to  the  local  subnetwork  protocol  for  transnlsslon  across  the  local  subnet* 

If  the  destination  host  is  on  the  local  subnet*  IP  sends  the  datagraa  through 
the  subnet  directly  to  that  host.  If  the  destination  host  is  on  a  foreign 
subnet,  IP  sends  the  datagraa  to  a  local  gateway.  The  gateway,  in  turn, 
sends  the  datagraa  through  the  next  subnet  to  the  destination  host,  or  to 
another  gateway^  Thus,  datagraas  aove  troa  one  IP  aodule  to  another  through 
an  interconnected  set  of  subnetworks  until  they  reach  their  destinatlonsi 
The  sequence  of  IP  aodules  handling  the  datagraa  in  transit  is  calleti  the 
gateway  route.  The  gateway  route  is  distinct  froa  the  lower  level  nodr-t<r- 
node  route  supplied  by  a  particular  subnetwotk,  Tlie  gateway  route  is  based 
on  the  destination  internet  address.  The  IP  aodujes  share  coaaon  rules  for 
interpreting  internet  addresses  to  perfora  internet  routing. 

4.2.3  Datagraa  processing  error.  Occasionally,  a  gateway  IP  or  dectinr- 
tion  IP  will  encounter  an  error  during  datagraa  processing.  Errors  detected 
nay  be  reported  via  the  Internet  Control  Message  Protocol  (ICMP)  which  is 
impleaented  in  the  internet  protocol  aodule. 

Eragaentation  and  reasseably  aechanisas.  In  transit,  datagraas  aay 
traverse  a  subnetwork  idiose  naxiaua  packet  sixe'is  saaller  than  the  siae 
of  the  datagram.  To  handle  this  condition,  IP  provides  fragaantation  and 
reasseably  aechanisas.  The  gateway  at  the  seal le repacks r  sublet  fragaents 
the  original  fJatagraa  into  pieces,  called  datagraa  fragaents,  ttiat  are  saall 
enough  for  transmission.  The  IP  aodule  in  the  destination  boat  reasaeaules 
the  datagraa  fragaents  to  reproduce  the  original  datagraa.  IP  can  support  a 
diverse  set  of  upper  Isyer  protocols  (ULPs).  A  traitjport  protocol  with 
real*’tlae  rt^quireaents ,  such  as  the  Network  Voice  Protocol  (NVP),  can  aaka 
use  of  IP'i  dategraa  aervlcv  directly.  A  tranaport  protocol  providing  ordered 
reliable  dcll^ry,  euch  at  TCP,  can  build  additional  aecHauteaa  on  top  of 
IF*e  basic  dstegraa  eervlcc.  Alao,  IP'e  delivery  aervict  can  be  cuetoaiaad 
in  soac  wnys  to  st:lt  the  apecial  needs  of  an  uppsr  layar  protocol.  For 
example,  j  predefined  gateway  route,  celled  e  source  route,  can  be  aupplled 
foi  an  Individual  datagram.  Each  IP  aodule  forvarda  the  date gram  according 
to  the  source  route  in  addition  to  using  the  standard  routing  aschanlsa. 
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4,2.5  IP  evolution.  The  current  Internet  Protocol  evolved  fron  proposals 
within  the  International  Federation  for  Infomatlon  Processing  (IFIP) 
Technical  Conalttee  6.1,  In  which  Internet  functions  and  reliable  transport 
functions  were  coablned  in  a  single  protocol.  Subsequent  developnent  of 
other  ULPs  Uuch  as  packet  speech)  led  to  the  separation  of  these  functions 
to  font  IP  ani  the  Transalsslon  Control  Protocol. 

4.3  Scenario.  The  following  scenario  Illustrates  the  oodel  of  operation 
for  transmlttit^  a  datagraa  fro*  one  upper  layer  protocol  to  another.  The 
scenario  is  purposely  simple  so  that  IP's  basic  operation  is  not  obscured  by 
the  details  of  interface  parameters  or  header  fields. 

4.3.1  Basic  model  of  operation.  A  ULP  in  host  A  is  to  send  data  to  its 
peer  protocol  in  host  B  on  another  subnetwork.  In  this  case,  the  source  and 
destination  hosts  are  on  subnetworks  directly  connected  by  a  gateway. 


HOST  A  HOST  B 


lOCAL  SUBNfT  1  LOCAL  SUBNiT  2 


FIGURE  3.  Basic  i^iodel  of  operation. 

a.  The  sending  ULP  passes  its  data  to  the  IP  module,  along  with 
the  destination  Internet  address  and  other  parameters. 

b.  The  IP  module  prepares  an  IP  header  and  attaches  the  ULP's 
data  to  font  an  internet  datagram*  Then,  the  IP  module  deter¬ 
mines  a  local  subnetwork  address  f^om  the  destination  Internet 
address.  In  this  case,  it  is  the  '^dress  of  the  gateway  to 
the  destination  subnetwork.  The  ;  '  wcnet  datagram  along  with 
the  local  subnet  address  Is  passv,u  o  the  local  subnetwork 
protocol  (SNP). 

c.  The  SNP  creates  a  local  subnetwork  header  and  attaches  it  to 
the  datagram  forming  a  subnetwork  packet.  The  SNP  then 
transmits  the  packet  across  the  local  subnet. 
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SUBNETWORK  PACKET 


FIGURE  4.  Subpttifotk  packtt» 

d.  Tht  pAckat  arrlvtt  at  the  fittvay  coanactlng  tht  first  and 
stcond  subnatsozksa  Tha  SHF  of  the  first  subnet  strips  off 
the  local  subnetiroik  header  and  passes  the  reaainder  to  the  IP 
■odulea 

e.  The  IP  aodule  detesiines  fros  the  destination  internet  address 
in  the  IP  header  that  the  datagran  is  intended  for  a  host  in 

the  second  subnet.  The  IP  nodule  then  derives  a  local  subnetvoik 
address  for  the  destination  host.  That  address  is  passed  aloi^ 
with  the  dategran  to  the  SNP  of  the  second  subnetvork  for  delivery. 

f.  The  second  subnet's  SNP  builds  a  local  subnetvoxh  header  and 
appends  the  datagrasi  to  form  •  packet  for  the  second  subnet** 
work.  That  packet  is  transnitted  across  the  second  subnet  to 
the  destination  host* 

g.  The  SNP  of  the  destination  host  strips  off  the  locnl  subnetwork 
header  and  hands  the  renaining  datagraa  to  the  IP  nodule. 

h.  The  IP  nodule  detemines  that  the  datifren  is  bound  for  a  ULP 
within  this  hoot.  The  data  portion  of  the  datagran  and  infor* 
nation  fron  the  IP  header  are  passed  to  the  ULP. 


Delivery  of  data  across  the  internet  is  collets. 
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5.  SERVICES  PROVIDSD  TO  UPPER  UYER 

S«l  Dsicrlption*,  Thlp  ssction  dsseribss  ths  ssrvlccs  offsrsd  by  ths  Infer- 
net  Protocol  to  upper  layer  protocols  (ULPa)*  The  goals  of  i:hia  section  are 
to  provide  the  Motivation  for  protocol  Mechanises  and  a  definition  of  the 
functions  provided  by  this  protocol*  The  services  provided  by  IP  are:  Internet 
datagraa  service,  virtual  netvork  service,  and  error  reporting  service*  A 
description  of  each  service  follows: 

5*2  PatagraM  service*  The  Internet  Protocol  shall  provide  a  datagraa 
service  between  hoMogeneous  upper  layer  protocols  In  an  Internet  snvlronMant* 

A  dstagraM  service  Is  characterised  by  data  delivery  to  the  destination  with 
nott-sero  probability;  sons  data  nay  possibly  be  lost  or  duplicated*  Also,  a 
dstagraM  service  does  not  necessarily  preserve  the  sequence  In  which  data  is 
supplied  by  the  source  upon  delivery  at  the  destination* 

5*2*1  Delivery  service*  IF  shall  deliver  received  data  to  a  destination 
UIP  In  the  saas  Com  as  sent  by  the  source  UtP*  IF  shall  discard  datagrans 
when  Insufficient  resources  are  available  for  processing*  IP  does  not  detect 
datagrsMS  lost  or  discarded  by  the  subnetwork  layer*  As  part  of  the  dellvtry 
service,  IP  Insulates  upper  layer  protocols  froM  subaeCwork*speclflc  charac¬ 
teristics*  For  example,  IP  maps  Internet  addresses  supplied  by  ULPs  Into 
local  addresses  used  by  the  local  subnetwork*  Also,  IP  hides  any  packs t’-slse 
reatrlctlons  of  subnetworks  along  the  transalssloa  path  within  the  internee* 

5*3  ^nerallicd  network  services*  IP  shall  provide  to  upper  layer  protocols 
the  ability  to  select  virtual  network  service  paraasters*  IP  shall  provide 
a  general  conaand  set  for  ths  ULPs  to  Indicate  the  services  desired*  Thus, 
the  ULPs  can  tune  certain  properties  of  IP  and  the  underlying  subnetworks  to 
custoadse  ths  transaleelon  service  according  to  their  needs* 

5*3.1  twork  pareaeters*  The  virtual  network  paraasters  fall  Into  two 
categories:  service  quality  paraasters  and  service  options*  Service  quality 
paraasters  influence  the  transmission  service  provided  by  the  subnetworke; 
service  options  are  additional  functions  provided  by  IP.  A  brief  description 
of  each  follows: 

*  Service  Quality  Paraasters 

*  Precedence:  attempts  preferential  treatment  for  high 
Importance  datagrams 

*  Transmission  Kode:  datagram  vs.  stream*  Stream  modn 
sttempte  to  minimise  delay  end  delay  dispersion  through 
reservation  of  network  resources 

~  Reliability:  attempts  to  minimise  data  lose  and  error 
rate 


-  Speed:  attmspts  prompt  delivery 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


MIL-STD-1777 
12  Aufuet  1983 


•  Utourcft  Tradtofft  lodlcAtM  rtlatlvt  lAportanc*  of  opood 

rtliabllity 

*  Sonrlct  Qptiooi 

-  Stcurlej  UbolUof!  UontiflM  dot^rn  for  c(«ii»ortMiitod 
hooti 

•  Sourco  loutlqg:  ioloeti  oot  of  gatmy  IP  aoduUi  to  vlilt 
in  troMlt 

•  loott  lococdlog:  roeordo  gotowoy  IP  aoduloi  ooeouiitorod  in 
troiMit 

-  ScrM  IdtotlfioitioB:  tkOBoo  rooonrod  rMoureoo  itood  for 
«tr««o  oorYlee 

•  TiMitfli^log:  roeordo  tim  lofonotion 

•  Doo't  ProgMoet  aorko  o  dotogroai  oo  on  indiotoiblo  vnlt 

grror  ^porting  oorolco,  IP  oholl  providt  error  roporto  to  tbo  upper 
lejrer  protocoU  lodleetlog  errore  detected  io  providing  the  ebove  eenrleee. 

In  eddltlon,  eerteln  erroie  detected  by  lower  leper  protocole  or  eoppUed 
In  lOIP  aeeeegeo  ehell  be  peeeed  to  the  We.  Theee  reporte  Indicate  eeeerel 
claeeee  of  erron  Inclodlni  Invalid  ergunente,  Ineufflclent  reeowreee,  ei^ 
trenenleeloo  errore.  The  erron  that  IP  nuet  report  to  OLPe  ere  to  be 
detecnlnod  for  each  Ijopleaentetlon. 
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6.  UPFBt  LAIU  SEEVICBAirrBKrACB  SPBCIFICATION 

P—cylPtloa»  Thlt  Mctlott  specif tte  IF  MtvleM  provided  to  uppor 
lojor  protoeolo  and  tho  Intorfaeo  tliroufh  which  th«M  oorvlcoo  aro  acctiaad. 
Tha  fine  part  daflaaa  tha  intaractlon  priaitlvaa  and  latacfaea  paranatara 
for  tha  uppar  intarfaca*  Tha  aaeond  part  eontaloa  tha  aba tract  aachlna  apaci- 
flcatlon  of  tha  uppar  layar  aarvleaa  and  Intaractlon  dlaclpllna* 

6*2  Intaractlon  prl»ltlaaa>  An  intaractlon  prlnltlaa  daflnaa  tha  purpoaa 
and  content  of  Infomatlon  axchaofad  batwaan  two  protocol  layara*  Frlnltlaaa 
ara  groopad  Into  tun  claaaaa  baaad  on  tha  dlractlon  of  Infomatlon  flow. 
Infomatlon  paaaad  dowaward.  In  thin  caaa  froai  a  OIF  to  IF.  la  eallad  a 
aarrlca  taquaat  prlaltlaa.  Infomatlon  paaaad  upward.  In  thla  caaa  from  IF 
to  a  OIF,  la  eallad  a  aarvlea  raaponaa  prlnltlaa*  Intaractlon  prlnltlaaff 
naad  not  occur  In  palra.  That  la.  a  aanrlca  raquaat  doaa  not  nacaaiarlly 
allclt  a  aarvlea  "raaponaa;*  a  aarvlea  "raaponaa*  nay  occur  Indapo’Jidantly  of 
a  aarvlea  raquaat*  T^  Infomatlon  aaaoclatad  with  an  Intaractlon  prlnltlva 
falla  Into  two  catoforlaa:  parmatara  and  data*  Tha  paranntara  daacrlba  tha 
data  and  Indicate  how  tha  data  ara  to  be  treated*  Tha  data  am  not  axanlnad 
or  aodlflad*  Tha  fomat  of  tha  paranatata  and  data  am  Inplanantatlon 
dependant  and  tharafom  not  apaelfled*  A  glmn  IF  Inplanantatlon  nay  have 
allfhtly  dlffamnt  Interaction  prlnltlvaa  Inpoaad  by  the  execution  aovlroaMnt 
or  apatan  daalpi  factom*  In  thoaa  caaea.  tha  prlnltlvaa  can  be  aodlflad  to 
Include  nora  Infomatloo  or  additional  prlnltlvaa  can  be  defined  to  aatlafy 
ayatan  raqulrananta*  Kownvnr.  all  IFa  mat  provide  at  leant  the  Interaction 
prlnltlvaa  apaelfled  below  to  fuarantee  that  all  IF  Inplanantatlona  can 
aupport  the  aane  protocol  hierarchy* 

6*2*1  Semlm  m^weat  prlnltlvm*  A  alqgla  aarvlea  raquaat  prlnltlva 
tupporta  ff^a  datafmn  aarvlea.  tka  SUD  prlnltlva* 

^*^*^*^  .9S*  prlnltlva  coatalna  conplata  control  Infomatlon 

for  aadi  unit  of  data  to  be  dalimred*  IF  aceapta  In  a  SUB)  at  leant  tha 
followlof  Infomatlon: 

*  aourca  addmaa  *  Intamat  addraaa  of  UIF  aendlni  data 

*  daatlaatlon  addraaa  **  Intamat  addraaa  of  OIF  to  racalva 
^ta  ' 

*  arococol  -  nana  cf  tha  raclplast  OLF 

*  type  of  aarvlea  Indlcatora  *  ralatlva  trananlaalott  quality 
aacociata^  with  vnlt  ol  iata 

-  pracadenca  *  one  of  eight  lavela  :  (FO.  FI,  F2.  F3,  F4, 
rS.  F6,  F7)  wiMm  FO  <-  FI  <-  P2  <-  F3  <•  P4  <-  F5  <-  P6 
<-  F7 

*  reliability  -  one  of  two  UvaU  :  (10.  11)  where  tO  <•  11 


U 
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•  dsUy  *  OM  of  Oro  Itvels  t  (D0»  Dl)  nhtrs  DO  <■  D1 
throughput  ~  OM  ci  tuo  lovult  t  (T0»  Tl)  vhoro  TO  <•  T1 

*  lor  -  ooXuo  optioaollp  providoA  bp  this  UUP  diotltk* 
guiihifig  thlo  portion  of  dots  froa  othort  tout  hf  thlo  UUP* 

-  doo*t  frog—ttt  IndiMtor  -  flog  ohovlog  ohothor  If  eon  frog*** 
aont  dots  to  oeeoapllolSrdoUMry 

*  tlM  to  llM  •  the  voluo  In  ooeoodo  uhleh  lodleotoo  tho  aoxiaua 
llfotlat  of  dots  althln  tho  Intomot*  Tlao^to^llao  It  doero- 
aontod  hf  om  oocond  for  ooeh  gotoaoy  tronoMtood* 

**  doto  longth  *  length  of  doto  hoing  tronoalttod 

*  option  doto  •  optlono  roquootod  hf  o  Ul/  froa  folloalni  list: 
ooeurltyV  loooo  or  strict  souroo  routing,  roeord  routing, 
otrooa  Idontlflcotlon.  or  tlBootaop  (ooctlon  9*3* U)* 

dots  •*  prsoont  uhsn  doto  length  Is  grootsr  then  torn* 

6*2.2  ^rvlM  rsspoMo  prlattlsM*  A  single  sorvleo  rasponss  prlaltlsn 
supports  tl^^s  dCtoi^oa  soriples.  tbs  DUXfll  prlaltlui* 

6*2*2. 1  ^IVltt*  Tbs  OilXfKt  prlaltlso  eontolot  the  dots  postod  hf  o 
soureo  Ulf  In  o  IttND.  olong  with  oddrsosl^.  quoUty  of  sorrleo.  ond  option 
Infoiaotlon*  If  possos  In  s  KttfEA  ot  loost  the  foUouing  Infotaotlon: 

**  noutf  sddross  *  Intsrnot  oddrsss  of  sending  UUP 

*  dost  loot  loo  oddrnss  *  IntorMt  sddrsos  of  the  rsclploat  Ulf 

*  Ptotoeol  *  noas  of  rselplsnt  Ulf  os  supplied  hf  the  sanding 


-  CTOS  of  sonriea  indlcotors  •  relotlee  tronsalsslon  ouolity 
ossoeisted  ^tk  ui^t  ol  lots 

prscodsnoi  *  om  of  sight  t  (fO.  fl.  f2.  f3»  f4. 

f5,  f6.  f7)  Uhore  fO  <-  fl  <•  f2  <-  f3  <•  H  <•  f5  <-  fi 
<-  fl 

*  delay  *  om  of  cwo  lovsls  :  (DO.  Dl)  uharo  DO  <•  D1 

~  TollohlUty  -  OM  of  tuo  levels  t  (PO.  tl)  vhere  80  <•  tl 

*  tbroufhpuc  -  oM  of  ore  levels  :  (TO.  Tl)  nhere  TO  <•  Tl 


doto  loMth  •  length  ^  roeelved  dots  (possibly  mm) 


MILITARY  STANDARDS:  IP 


MIL-STD  1777 


MIL-STD-1777 
12  August  1983 


-  option  data  ”  options  requested  by  source  ULP  from  folloving 
list:  security,  loose  source  routing,  strict  source  routing, 
record  routing,  stress  identification,  or  tinestanps  (sec-' 
tion  6.2.14), 

-  data  -*  present  when  data  length  is  greater  than  zero* 

In  addition,  a  DELIVER  oust  contain  error  reports  fros  IP  either  together 
with  peraaeters  and  data  listed  above,  or  independent  of  that  information. 

6.3  Extended  state  machine  specification  of  services  provided  to  upper 
layer.  The  extended  state  machine  defines  the  behavior  of  the  entire  service 
machine  from  the  perspective  of  the  upper  layer  protocol.  An  extended  state 
machine  definition  is  composed  of  a  machine  instantiation  identifier,  a 
state  diagram,  a  state  vector,  a  set  of  data  structures,  an  event  list,  and 
an  events  and  actions  currespondence. 

6.3.1  Machine  instantiation  identifier.  Each  upper  interface  state  machine 
is  uniquely  identified  by  the  four  interaction  primitive  parameters:  source 
address,  destination  address,  protocol «  and  Identifier.  One  state  machine 
instance  exists  for  the  SEND  and  DELIVEK  primitives  whose  four  parameters 
carry  identical  values. 

6.3.2  State  diagram.  The  upper  interface  state  machine  has  a  single  state 
which  never  changes.  No  diagram  is  needed. 

6.3.3  State  vector.  The  upper  interface  state  machine  has  a  single  state 
which  never  changes.  No  state  vector  is  needed. 

6.3.4  Data  structures.  For  clarity  in  the  events  and  actions  section,  data 
structures  are  declared  for  the  interaction  primitives  and  their  parameters. 

A  subset  of  Ada^  data  constructs,  common  to  most  high  level  languages.  Is 
used.  However,  a  data  structure  may  be  partially  typed  or  completely  latyped 
where  specific  formats  or  data  types  ire  implementation  dependant. 

6.3.4. 1  From  ULP.  The  fromJULP  structure  holds  the  Interface  parameters 
and  data  associated  with  the  SEND  primitive  specified  above.  This  structure 
directly  corresponds  to  the  from^ULP  structure  declared  in  9. 4. 4. 2  of  the 
mechanism  section.  The  fromJJLP  structure  is  declared  as: 

type  fromJULP^type  is 
record 
sourcejiddr 
des t 1 na t lon^add r 
protocol 

type  of  service  is 


^Ada  la  a  registered  trademark  of  the  Department  of  Defense  (Ada  Joint  Program 
Office). 
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record 

precedence 

delay 

throughput 
reUability 
end  record; 

Identifier 

dont^fragoent 

tlae^to^llve 

length 

options 

data 

end  record; 

6. 3. 4.2  To  ULP.  The  toJJLP  structure  holds  Interface  parameters  and  data 
associated  with  the  DELIVER  primitive,  as  specified  In  section  6.2.2.  This 
structure  directly  corresponds  to  the  to^ULP  structure  declared  In  9*4.4.3 
of  the  mechanism  specification.  The  toJLILP  structure  Is  declared  as: 

type  to_ULP_type  Is 
record 
sourcejiddr 
des  1 1  r.a  t  lon^add  r 
protocol 

type__of_servlce  Is 
record 

precedence 

delay 

reliability 

throughput 

end  record; 
length 
options 

data 

error 

end  record; 

6.3.5  Event  list.  The  events  are  drawn  from  the  interaction  primitives 
specified  in  section  6.2  above.  An  event  Is  composed  of  a  service  primitive 
and  an  abstracc  timestamp  to  Indicate  the  time  of  event  Initiation.  The 
event  list  is  as  follows: 

a.  SEKD(  fro«_ULP  )  at  time  t 

b.  NULL  -  Although  no  service  request  is  Issued  by  a  ULP ,  cer¬ 
tain  conditions  within  IP  or  lower  layers  produce  a  service 
response.  These  conditions  can  Include  duplication  of  data 
and  subnet  errors. 


16 
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6,3.6  Events  sad  Actions.  The  following  section  defines  the  set  of  possible 
sctlov  elicited  by  each  even:. 

6.3.6,!  EVENT  ■  SEND  (froa  ULP)  at  time  t. 

Actions: 

1.  DELIVER  toJJLP  at  tine  t+N  to  the  protocol  designated  by 
froB  ULP.protocol  at  destination  fronJJLP.destlnatlon^addr 
wlth"*all  of  the  following  properties: 

a.  The  tine  elapsed  during  data  transnlsslon  satisfies 
the  tlne-to-llve  Unit,  l.e*,  N  <•  fronJJLP.tlne^ 
to_llve. 

b.  The  quality  of  data  transnlsslon  Is  at  least  equal 
to  the  relative  levels  specified  by  fronJJLP, type_ 
of__servlce. 

c.  If  (franJUlJP.dont__fragnant  -  TRUE)  then  IP  fragneit- 
tatlon  has  not  occurred  In  transit. 

d.  if  (fronJULP. opt Ions  Includes  loose  source  routing) 
then  toJULP.data  has  visited  In  transit  at  least 
the  gateways  naned  by  source  route  provided  by  SEND* 

e*  if  (frcni_ULP. opt loos  Includes  strict  source  rout¬ 
ing)  then  toJJLP.data  has  visited  in  transit  only  the 
gateways  naned  by  source  route  provided  by  SEND. 

f.  if  (fronJULP. options  Includes  record  routing)  then 
the  Ust  of  nodes  visited  in  transit  Is  delivered 
In  toJJlP. 

g.  if  (fronJULP. options  Includes  security  labelling) 
then  the^'securlty  label  la  delivered  In  toJULP. 

h«  If  (fronJULP.uptlons  Includes  strean  Identifier) 
then  the'^streaa  Identifier  la  delivered  in  toJLiLP. 

1.  If  (fronJJLP.op lions  includes  Internet  tlaestaap) 
then  the'^lnternct  tlacstanp  Is  delivered  In  toJJLP. 


OR, 


2.  DELIVER  to  the  protocol  designated  by  fronJULP. protocol  at 
aource  fronJULP.source^addr  indicating  one  of  the  following 
error  conditions: 


a.  destination  froa  ULP. destination  addr  unreachable 
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b,  protocol  frcaJULP .protocol  unroschsble 

c.  If  (froBjJLP.dont_frag«6iit  «  TRUE)  thtn  frsgwntstlon 
nooJed  but  prohibited 

(froa^DlP.  opt  loos  cootslos  siqr  optloo)  thtn  psr^Mttr 
problea  with  option. 

OR, 

3.  no  action 
6. 3.6.2  EVEHT  ■  WUIJ.. 


Actions: 

1.  DELIVER  to  the  protocol  designated  Uy  from  ULP. protocol  at 
source  froaJJLP. source  addr  Indicating  the^followlof  error 
condition:  ^ 

a.  error  conditions  In  subnet  layer 


OR, 


2.  DELIVER  toJJLP  at  tlae  t+H  to  the  protocol  designated  by  froa 
ULP. protocol  at  destination  froaJtJLP. destination  addr  with  * 
all  of  the  following  properties:**  ^ 

a.  The  tlae  elapsed  during  data  transalssion  satlsflM  the 
tlae-to-llse  Halt,  l.e.  K  <-  froBjnJP.tlMj_to_llve. 

b.  The  quality  of  data  transalssion  Is  at  least  equal  to 

the  reUtlve  levels  specified  by  froa  ULP.  type  of 
service.  — 

c.  If  (froa_ULP.doot_fragaent  -  TRUE)  then  IP  fragaintatlon 
has  not  occurred  in  traialt. 

d.  If  (frcaUl^.  opt  Ions  Includes  loose  source  routing) 
then  teJ[fLP.data  has  visited  In  transit  at  least  the 
gatarays  naaed  by  source  route  provided  la  SEND. 

a.  If  ( froa^UlJP. options  Includes  strict  source  routing) 
then  tqJ^LP.data  has  visited  In  transit  only  the  gatw 
ways  naaed  by  source  route  provided  la  SEND. 

f.  If  (froeJJLP. opt loos  Includes  record  routli^)  then  the 
list  of  nodes  visited  In  transit  Is  delivered  In  toJJLP. 

g.  If  (froe^ULP .options  Includes  security  labelUi^)  then 
Che  security  label  Is  delivered  In  to  ULP. 


I 
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7.  SERVICES  REQUIRED  FROM  LOWER  UTER 


7.1  Description, 
the  subnetwork  Isyer. 
between  hosts  within 
eseh  service  follows. 


This  section  describes  the  winiBsl  services  required  of 
The  services  required  ere:  trensperent  dets  trewfer 
e  subnetwork  end  error  reporting.  A  description  of 


transfer.  The  subnetwork  Isjer  itust  provide  s  trewperent  data 
t.aMfer  between  hosts  within  a  single  subnetwork.  Only  the  data  to  be 
deli^r^,  and  the  necessary  control  and  addressii«  inforeation  should  be 

rating  and  aubnatmrk  opar.tloo  thai 
Th.  aubaatirotk  nead  aoe  ba  a 
‘hooH  arriva  with  oon-aaro  probablUey 
at  a  daatloatlon.  Data  m»j  not  nteaaaarilj  arrlaa  In  tha  aaaa  ordar  aa  it 
waa  auppUed  to  tha  aubnatvork  layar,  nor  la  data  guarantaad  to  arriva  arror 


7.3  Error  raportlng.  The  aubnatwotk  layar  ahall  provide  reporta  to  IP 
Indicting  arrota  fro.  tha  aubnatwork  and  loiwr  layata  aa  faaalbla.  Tha 
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8.  LOWER  LAYER  SERVICE /IHTERFACZ  SPECIFICAnON 


8.1  Dsscrlptlon.  This  section  specifies  the  «lnlasl  subnetwork  protocol 
services  required  by  IP  end  the  interfsce  through  which  those  services  sre 
scoessed.  The  first  pert  defines  the  internet  Ion  primitives  end  their  psrsmr 
eters  for  the  lower  interface*  The  second  pert  contains  the  abstract  machine 
specification  of  the  lower  layer  services  and  interaction  discipline* 

8*2  Interaction  primitives*  An  interaction  primitive  defines  the  purpose 
of  information  exchanged  between  two  protocol  layers*  Two  kinds  of  primitives, 
based  on  the  direction  of  information  flow,  are  defined*  Service  requests 
pass  information  downward;  service  responses  pass  information  upward*  These 
primitives  need  not  occur  in  pairs,  nor  in  a  synchronous  manner*  That  is, 
a  request  does  not  necessarily  elicit  a  "response;”  a  "response"  may  occur 
independently  of  a  request*  The  information  associatud  with  an  interaction 
primitive  fails  into  two  categories:  parameters  and  date*  The  parameters 
describe  the  data  and  indicate  how  the  data  are  to  be  treated*  The  data  are 
not  examined  or  modified  arid  the  format  of  interaction  primitive  information 
is  implemsntation  dependent  and  is  therefore  not  specified.  A  given  IP 
implementation  may  have  slightly  different  interfaces  imposed  by  the  nature 
of  the  subnetwork  or  execution  environment*  Under  such  circumstances,  the 
primitives  can  be  modified  to  either  include  more  parameters  or  have  eddi- 
tional  primitives  defined*  Rowevtri  all  IPs  must  provide  at  least  the 
interface  specified  below  to  guarantee  that  all  IP  implementations  can 
support  the  same  protocol  hierarchy* 

8*2*1  Service  request  primitives*  A  single  service  request  primitive  is 
required  from  rim  SNP,  a  SMP^SEND  primitive* 

8*2*1*1  yyp*  The  SHP^SEIU)  contains  an  IP  datagram,  a  destination,  and 
parameters  Ascribing  the*” desired  transmission  quality*  The  SHP  receives 
in  an  SNPJIBMD  at  least  the  following  infoi'vntion: 

*  local  destination  address  ~  local  subnetwork  address  of  destina¬ 
tion  host  or  gateway 


type  of  service  indicators  -  relative  transmission  quality 
associated  wltK  the  datagram 

-  precedence  -  one  of  eight  levels:  (PO,  PI,  P2,  P3,  P4, 
P5,  PA.  P7)  where  PO  <•  PI  <-  P2  <•  P3  <•  P4  <•  P5  <-  PA 
<-P7 


-  reliability  -  one  of  two  levels: 

-  delay  -  one  of  two  levels:  (DO, 

-  throughput  -  one  of  two  levels: 

-  length  -  slse  of  the  datagram 

-  datagram 


(RO,  Rl)  where  RO  <•  R1 
01)  where  DO  <•  D1 
(TO,  Tl)  where  TO  <-  Tl 


i-u:. 
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8*2.2  Servic.1t  fponte  priaitivt.  Ont  lervlce  reaponse  prlaitlvc  it 
required  to  tupport  IP*t  detegree  tervice,  the  SNPJDELIVER  priaitive* 

8.2.2. 1  lUff  DELIVER.  The  SNPJ«LIVBR  conteim  only  e  detegrea  vSieh  it 
en  independent  entity  containing  en  IP  header  end  date.  An  IP  receivet  in 
an  SNPJ)ELIVER  at  leant  the  following  infotaation: 

-  datagraa 

In  addition,  a  SNP^KLIVER  nay  contain  error  reports  froa  the  SHP.  either 
together  with  a  daTagraa  or  independent  of  one* 

8.3  Extended  state  atchine  specification  of  tervicet  required  froa  lower 
layer.  The  extended  state  aachlne  defines  the  behavior  of  the  entire  service 
atchine  with  respect  to  the  lower  layer  protocol*  An  extended  state  aachioe 
definition  is  coaposed  of  a  aachine  inatantiation  identifier,  a  state  diagraa. 
a  state  vector,  a  set  of  data  structures,  an  event  litt.  and  an  events  and 
actions  correspondence. 

8.3.1  Machine  iMtentiation  identifier.  Each  lower  interface  state  aachlne 
is  uniquely  Identified  ^y  tKe  four  values: 

-  source  address 

-  destination  address 

*  protocol 

*  identification 

These  values  are  drawn  froa  header  fields  of  the  datagraa  passed  by  the 
SEND  and  SNP^DEtlVER  prlaltives.  One  state  aachine  instance  exists  for  the'^ 
interaction  ^riaitlves  whose  parsastera  carry  the  saae  values. 

8.3.2  State  diagraa.  The  lower  interface  state  aachlne  has  a  single 
state  which  never  changes.  No  diagraa  is  needed. 

8.3.3  State  vector.  No  state  vector  is  needed  for  the  lower  interface 
state  asekine. 

8.1.4  Data  structures.  For  clarity  in  Che  events  and  actions  section, 
data  structures  are  declared  for  the  Interaction  prlaltives  and  their  psraae* 
tecs.  These  structures  are  declared  In  a  subset  of  Ada  coaposed  of  constructs 
coaaon  to  aost  high  level  languages.  Mowever.  a  data  structure  aay  be  per* 
daily  typed  or  completely  untyped  where  specific  focaats  or  data  types  are 
iapleatntation  dependent* 

8.3*4. 1  Froa  SNP.  The  froajSNP  structure  holds  the  Interface  parsaeters 
and  datagraa  associated  with  the  SNF^DELIVIR  priaitlve.  aa  specified  in 
section  8. 2. 2.1  This  structure  directly  corresponds  to  the  froa^SNP  structure 
declared  in  oectlon  9.4. 4. 4  of  the  aechsnlsa  specification.  The  froa^SNF 
structure  is  declared  as: 
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typs  fro«J5!IP_typs  It 
rscord 

•  our  cs^dt  •  t  lost  loo^sddr 
dtf«:  dstsgrta^typs; 
srror 

sud  rscord; 

Tbs  dtf«  sUMUt  Is  itsslf  s  strueturs  ss  spsciflsd  bslow. 

8.3.4.2  To  SHP.  Tbs  to  SMP  ttructurs  bolds  tbs  dsts  sod  psrsastsrs 
sssodstsd  vltV  tbs  SKF^SIMD  prlAitlrs  spsciflsd  In  ssetlon  8.3.1  •  Tbls 
stnicturs  dlrsctly  corresponds  to  tbs  to_S»  stnicturs  dscisrsd  In  ssetlon 
9.4.4. S  of  t\m  Mchsnlsn  spsclf lestlon.  “tbs  toJIW  stnicturs  Is  dscisrsd  ss: 

typs  to_S!IP_typs  Is 
rscord 

locsl^dss  t  Instlon^^dr 
typsJof_ss  nrlcs^lndlcstors 
Isngth 

dtfs:  dstsgrssi^typs: 
snd  rscord; 

Tbs  dtfs  slsssnt  Is  Itsslf  s  ttructurs  ss  spsciflsd  bslow. 

8.3.4. 3  Dtts.  Tbs  dtgs  stnicturs  bolds  s  dstsgrsa  ssds  up  of  s  hssdsr 
ponlon  sid  s  dsts  portion  ss  spsciflsd  In  ssetlon  9.3.  4  dtgs  ttructurs  Is 
dscisrsd  ss: 

typs  dstsgrsB^typs  Js 
rscord 

ssrslon:  BAX.FJXTST; 
bssdsr_lsngtb:~  RALFJOCTET; 
typs  d^ss ivies:  OCTET; 
totsT^lsngth:  TWOJOCTETS; 
ids  ntTf  lestlon:  TVOJOCTSTS; 
dont__frsg__flsg:  lOOLEAll; 

«>rs  frsg  flsg:  lOOUAN; 

f  rsgisnt^of  f  sst :  OKEJI^f  IVEJtlGHTlSjOCrETS; 
tlss^to^Uvs:  OCTET; 
pi'^^tecol:  OCTET; 
bonds  r^chseksos:  TVOJ3CTETS ; 
sourcs^sddr:  FOUl^OCIETS; 
its  c  Inst  lonjsddr:  FOmMXTETS; 
options:  ope  loo  typs;  ~ 
dsts:  srrsy(l..iATA_LE)K;TB)  of  TIfTBOEt; 
snd  rscord; 

subtyps  SALE  OCTET  Is  IWTBlEt  rsngs  0..1S; 
subtyps  oenf  Is  HrrEGU  rsngs  0..255; 

subtyps  OIIE_N_riVE  EIGHTHS  OCTETS  Is  HfTKEE  rsngs  0..8191; 
subtyps  TVO  OCrETS*’ls  IHttdOL  rsngs  0.. 65533; 
subtyps  rout  OCTETS  Is  lirrBGEE  rsngs  0.  .4294967295; 
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Rvot  list.  Tht  cventt  art  dravn  from  tht  Mtvlce  prluitivtt 
iptclfled  In  stctlon  5,1  abovt.  An  tvant  la  coapoaad  of  a  aarvlct  prlaltlvt 
with  its  paraattan  and  data. 

a.  SMP^SEND  (tojSHP) 

b.  NULL  -  Although  IP  iaauaa  no  aeivlca  raquaat,  certain  coadltlofw 
within  the  aubnat  layer  elicit  a  aenrlca  raaponaa. 

^•3.6  Eeenta  and  act Iona.  The  following  aectlon  daflnaa  tha  aat  of  poaalbla 
actlona  elicited  by  each  eetnt. 

8. 3.6.1  EVENT  «  SNP  SEND  (to  SNP). 


ACTIONS: 

SNP^DELIVEE  Datagrae  to  IF  at  local  daatlnation  (LD)  with 
all  of  the  following  propertlea: 

a.  Tha  quality  of  data  tranaelaaf.on  la  at  laaat  equal  to 
tha  ralatiae  lavela  apeclflad  by  to^SNP. type^of^aar- 
vlca.  “  —  — 

CE, 

2.  no  action 
8. 3.6. 2  EVENT  *  NULL. 


ACTIONS; 

!•  SNPJDELIVER  frae^SNP  Indicating  tha  followlrq^  error  condition: 
a.  error  condltlooa  within  the  aubnat  layer 
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9.  IP  ENTITY  SPECIFICATION 

D<«crlptlon>  This  section  defines  the  sechsnlsits  of  sn  IP  entity 
supporting  Che  services  provided  by  the  IP  service  luchiiie*  The  first 
subsection  aotlvetes  the  specific  aechenlsas  chosen  end  describes  their 
operation.  The  second  subsection  defines  the  foraat  and  use  of  the  IP  header 
fields*  The  last  subsection  specifies  an  extended  state  aachlne  representa¬ 
tion  of  Che  protocol  entity.  The  Inpleiwntstion  of  a  protocol  entity  aust 
be  robust.  Each  lapleaer.tatlon  aust  expect  to  Interoperate  with  others 
crested  by  different  Individuals.  While  the  goal  of  this  specification  is 
to  be  explicit  about  the  entity  aechanlsae,  there  is  always  the  possibility 
of  differing  interpretations.  In  general,  an  iapleaentation  aust  be  conser* 
vstlve  in  its  sending  bchsvlor,  snd  liberal  In  its  receiving  behovior.  That 
is,  it  aust  be  careful  to  send  well-fonsed  datagraaa,  but  aust  accept  any 
datagraa  that  it  can  Interpret. 

9.2  Overview  of  IP  aechanisas.  The  IP  aechanisivs  are  aotivated  by  the 
IP  services,  described  in  section  5  are  datagraa  delivery  service,  virtusl 
network  service,  and  error  reporting  service.  Each  service  could  be  sup¬ 
ported  by  any  of  a  sec  of  aechsnisas.  The  selection  of  aechanisas  is  guided 
by  design  standards  including  siapllcity,  generality,  flexibility,  and 
efficiency.  The  following  aechanisa  descriptions  identify  the  service  or 
services  supported,  discuss  the  design  criteria  used  in  selection,  and  explain 
how  the  aechanlsaa  work. 

9.2.1  touting  aechanisa.  If  contains  an  adaptive  routing  aechanisa  Co 
support  the  delivery  service.  The  routing  aechanisa  uses  the  internet 
addressing  scheae  and  internet  topology  data  to  direct  datagrsas  along  the 
best  path  between  source  snd  destinstlon.  The  aechanisa  provides  routing 
options  for  ULPs  needing  the  flexibility  to  select  routes  and  record  routing 
Inforaation.  A  distinction  is  asds  bttwesn  nsats,  addressss,  and  routes.  A 
naac  indicates  the  object  sought,  independent  of  physicsl  location.  An 
addreaa  indleatta  where  the  object  is  snd  s  route  indicates  how  to  get  there. 
It  is  the  task  of  the  upper  Liyer  protocols  to  asp  froa  naaes  to  addresses. 

The  internet  protocol  asps  froa  Internet  eddressee  to  local  subnet  addresses 
to  perfora  routing  through  the  internet.  It  is  the  task  of  lower  layer 
protocols  to  routs  the  datsgraa  to  the  spproprlste  local  subnet  destination 
addreaaea. 


9.2. l.l  Internet  addreaset.  Internet  addresses  have  a  fixed  length  of 
four  octets  bits).  An  internet  address  begins  with  s  network  nuaber 
followed  by  a  local  address  (called  tlte  REST  field).  To  provide  for  flex¬ 
ibility  In  asaigning  addresses  to  networks  and  allow  for  the  Urge  number  ot 
aaall  to  aedlux  atsed  networks,  there  sre  four  foraati  or  cUsses  of  Internet 
addresses.  These  classes  are  shown  In  the  following  dlagraa: 
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0  1  2  3 


II 


0  1  2  3 

01234St7tiC1  234ftt7tt01  ^ttOI 


["  1 

CLASS  t 

1  0 

NfTWOAX 

LOCAL  ADOPtSS 

..Ju- 

14  MTt  Of  NIT  It  MTS  Of  HOST 


CLASS  c 


0  12  3 


1  2  3 

•  0  ^.2tt01234it7tt01 

I  ■'  t-ry  yr  t-t't  t  f 


i  i  jy  /I  i  I,,  I  ,  I  .1  .A.  I„,i . InU,  mA,  I 

f OMAAT  UNDffMtO 


flGlEC  5.  Ipttrott  tddrttttt* 

9»2.1«1«1  Ittttrott  t^drtiiipg  cltiitt.  In  *elMt  •»*  th«  high  ordtr  Mt 
it  stro,  Cht  next  tevtp  Met  tptcify  th«  nteuoct,  tnd  tht  Ittt  24  bits  tptrlfj 
tn«  loctl  t84rttt«  It  'cLitt  b,*  the  high  order  two  bltt  ere  one-tero,  the 
next  14  bite  ere  the  netweit  end  cht  Utt  14  bite  ere  the  lecel  tddreet.  Ip 
*eUtt  €»*  the  high  ordtr  three  bite  ere  ope*-one-tere ,  the  nest  21  bite  ere 
Che  petvorti  end  the  Uti  eight  Mtt  ere  the  locel  s.1^rett«  Ip  the  extended 
eddreetipg  eittt,  the  high  order  three  bite  are  one-one-one,  the  next  29 
bict  he«c  no  defined  femet*  The  p«pflnR  betireen  internet  eddrettet  end 
locel  new  eddrettet  should  ellov  t  tingle  |.hveicel  host  to  set  ee  teverel 
ditetnee  internet  hotCt.  Alto,  to«e  hotte  will  tu'fm  teverel  pl^ticel  intet^ 
fecet  (i.e.,  be  eulti-^honed).  Thet  it,  provition  nutt  be  nede  for  t  host  to 
heve  teterel  phytietl  Interftcet  to  e  eubnetuoih,  vlth  etch  heving  teeerel 
Icglcfl  Internet  eddrettet. 


0 

0  1 


fXItNOCD 

AOOAfSSeiO 

CLASS 


h 

Li 

-iJI 

■T— fTT* 
,.i,S  .l  .S 


9.2. 1.1.2  Detetcen  routing.  To  route  e  deteerat,  en  IF  nodule  exeainee 
the  NTTVOAX  field  of  the  internet  eddrett  indiceting  the  dettlnetion  for  the 
det Agree.  If  the  neteoHc  nunber  it  the  sene  et  the  IF  nodule's  tubnetuorii, 
the  nodule  uses  the  REST  field  of  the  internet  eddrett  to  derive  the  local 
subnet  eddrett  of  the  detcinetion  host.  If  the  netuoth  nunber  does  not 
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natch »  tite  nodule  dete mines  a  local  subnet  address  of  a  gateway  on  the  best 
path  to  the  destination  subnetwork.  In  turn,  the  gateway  IP  aodule  derives 
the  next  local  subnet  address  to  either  a  host  or  gateway.  In  this  way,  the 
datagram  Is  relayed  through  the  Internet  to  the  destination  hoot.  In  a 
static  environment  the  routing  algorithm  Is  straightforward.  However, 

Internet  topology  tends  to  change  due  to  hard%rare  or  software  failure,  host 
availability,  or  heavy  traffic  load  conditions.  Therefore,  each  host  and 
i^ateway  IP  along  the  gateway  route  also  uses  Its  current  knowledge  of  internet 
topology  to  make  routing  decisions. 

9,2. 1,2  Routing  options.  IP  provides  a  mechanism,  called  source  routing, 
to  supplement  the  gateway's  Independent  routing  decisions.  This  mechanism 
allows  an  upper  layer  protocol  to  Influence  the  gateway  route  In  which  a 
datagram  traverses.  The  ULP  can  pass  a  list  of  Internet  addresses,  called  a 
source  route  list,  as  one  of  the  SEND  service  request  parameters.  Bach 
address  on  the  list,  except  for  the  last.  Is  an  intermediate  gateway  destina¬ 
tion.  The  last  address  on  the  Ust  Is  the  final  (Jestlnatlon,  The  source  IP 
module  uses  Its  noraal  routing  mechanism  to  transmit  the  datagram  to  the 
first  address  In  the  source  route  list.  Then  the  gateway  IP  replares  source 
route  list  entry  with  Its  own  address  as  known  In  the  environment  into  which 
it  is  forwarding  the  datagram.  Thus,  the  datagram  follows  the  source  route 
while  recording  Its  “Inverse"  or  recorded  route. 

9.2. 1.2.1  Routing  types.  Two  klais  of  source  routing  are  provided  by  IP: 
loose  and  strict.  With  loose  source  routing,  the  host  and  gateway  IP  modules 
along  the  route  may  use  argr  number  of  other  Intermediate  gateways  to  reach 
the  addresses  In  the  eource  Ust.  With  strict  source  routing,  the  datagram 
must  travel  directly  (l.e.  through  only  the  directly  connected  subnetwork 
Indicated  by  each  address)  to  each  address  on  the  source  Ust.  When  the 
source  route  cannot  be  followed,  the  source  host  IP  Is  notified  with  an 
error  message.  For  testing  or  diagnostic  purposes,  a  ULP  can  acquire  a 
datagram's  record  route  (Independent  of  the  source  route  option)  by  using 
the  record  route  mechanism.  The  sending  ULP  suppUes  an  empty  record  route 
list  and  indicates  that  the  gateway  route  is  to  be  recorded  In  transit. 

Then,  as  each  gateway  IP  nodule  on  the  gateway  route  relays  the  datagram,  It 
adds  Its  midress  as  kno%rn  "n  the  succe*idlng  environment  to  the  record  route 
Ust.  The  destination  ULF  receives  the  orlgl’'-al  datagram  along  with  the 
record  route  Ust  which,  if  reversed,  provides  a  source  route  to  the  sending 
ULP.  If  more  gateways  are  traversed  than  can  be  records !  in  the  list,  thn 
additional  gateway  addresses  are  not  recorded.  Problems  with  the  record 
route  option  discovered  In  transit  are  reported  to  the  source  hoet  IP. 

When  usli«  a  routing  option,  the  eource  ULP  must  provide  e  Urge  enough 
route  Ust  to  accomaadate  all  the  rooting  Information  expected.  The  site 
of  a  routing  option  does  not  change  due  to  adding  addresaes. 

9.2.2  Fragmentation  and  reassembly.  IP  contains  a  fragmentation  mechanism 
foi  breaking  a  Urge  datagram  into  smaller  datagrams.  This  solution  to  the 
problems  arising  from  the  difference  between  variable  aubnetwork  capacity 
provides  greater  flexibility  than  Ugialaclng  a  restrictive  datagram  alse 
that  la  sufficiently  small  for  any  aubnetwork  on  the  internet.  This  mechanism 
can  be  overldden  usl(«  the  "don't  fragment*  option  to  prevent  fragmentation. 

IP  also  contains  a  reassembly  mechanism  which  reverses  the  fri^mentation  to 
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enable  delivery  of  Intact  data  portions*  Normally»  fragaentation  is  per- 
fomed  only  by  the  IP  nodules  in  gateways.  There  is  no  need  for  fragaentation 
of  datagrams  within  the  IP  nodules  of  hosts  since  the  anount  of  data  supplied 
by  a  source  ULP  can  be  linited,  thereby  avoiding  datagraas  which  are  too  big 
to  be  transnitted  through  the  subnetwork  to  which  the  host  is  attached*  When 
an  IP  nodule  encounters  a  datagram  that  is  too  big  to  be  transnitted  through 
a  subnetwork,  it  applies  its  fragmentation  nechanisn*  First,  the  nodule 
divides  the  data  portion  of  the  datagram  into  two  or  more  pieces*  The  data 
nust  be  broken  on  8-t>ctet  boundaries*  For  each  piece,  it  then  builds  a  data¬ 
gram  header  containing  the  identification,  addressing,  and  options  infomation 
needed*  Fragmentation  data  is  adjusted  in  the  new  headers  to  correspond  to 
the  data's  relative  position  within  the  original  datagram.  The  result  is  a 
set  of  small  datagrams,  called  fragments,  each  carrying  a  portion  of  the 
data  from  the  original  large  datagram*  Section  9*4.6*3*7  defines  the 
fragmentation  algorithm* 

9 ,2*2*1  Fragment  routing*  Each  fragment  is  handled  independently  imtil 
the  destination  IP  module  is  reached*  The  fragments  may  follow  different 
gateway  routes  as  internet  topology  and  traffic  conditions  change*  They  are 
also  subject  to  further  fragmentation  if  'amaller-packet'  subnetworks  are 
subsequently  traversed*  Every  IP  module  nust  be  able  to  forward  a  datagram 
of  68  octets  without  further  fragmentation*  This  sise  allows  for  a  header 
length  of  up  to  60  octets  and  the  minimum  data  length  of  8  octets* 

9*2* 2*2  Fragment  ressseaably*  To  reassemble  fragments  into  the  original 
datagram,  en  IF  module  combines  all  those  received  having  the  sane  value 
for  the  identification,  source  address,  destination  address,  security,  and 
protocol*  IP  allocates  reassembly  resources  when  a  *'first*-to*arrive'' 
fragment  is  recognised*  Based  on  the  fragmentation  data  in  the  fragment's 
header,  the  fragment  is  placed  in  a  reassembly  area  relative  to  its  position 
in  the  original  datagram*  When  all  the  fragments  have  been  received,  the 
I?  module  passes  the  data  in  its  original  form  to  the  destination  ULP*  All 
hosts  must  be  prepared  to  accept  datagrams  of  up  to  576  octets  (whether  they 
arrive  whole  or  in  fragments)*  It  is  recommended  that  hosts  send  datagrams 
larger  than  576  octets  only  if  they  have  assurance  that  the  destination  is 
prepared  to  accept  the  larger  datagrams*  The  rumber  576  is  selected  to 
allow  a  reasonable  anount  of  data  to  be  transmitted  in  addition  to  the 
required  header  information*  For  example,  this  slxe  allows  a  data  block  of 
512  octets  plus  64  header  octets  to  fit  in  a  datagram*  The  maximum  internet 
header  sise  is  60  octets,  an;^  a  typical  internet  header  is  20  octets,  allowing 
a  margin  for  headers  of  upper  layer  protocols* 

9*2*2*3  Fragment  loss*  Because  the  subnetwork  may  be  unreliable,  some 
frajaeats  making  up  a  complete  datagram  can  be  lost*  IP  uses  the  *tiae-to- 
Uve*  data  (explained  in  section  9*2*4  below)  to  set  a  timer  on  the  reassembly 
process*  If  the  timer  expiree  before  all  the  fragments  have  been  collected, 

IP  discards  the  partially  reassembled  datagram*  Only  the  destination  IP 
nodule  should  perform  reassembly*  This  recommendation  is  intended  to  reduce 
gateway  overhead  and  minimise  the  chance  of  deadlock*  However,  reassembly 
by  private  agreement  between  gateways  is  transparent  to  the  rest  of  the 
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internet  and  is  allowed.  A  ULP  can  prevent  its  data  fro«  being  broken  into 
smaller  pieces  during  transmission.  IP  provides  an  override  mechanism  to 
prohibit  fragmentation  called  "don't  fragment."  One  example  of  the  "don't 
fragment"  iMchanism  is  the  down  Une  loading  cf  a  small  host  containing  only 
a  simple  boot  strap  program  to  accept  data  from  a  datagrw,  storing  it  in 
memory,  and  executing  it.  Any  internet  datagram  marked  "don't  fragment" 
cannot  be  fragmented  by  an  IP  module  along  the  gateway  route  under  any 
circumstances.  If  an  IP  module  cannot  deliver  such  a  datagram  to  its 
destination  without  fragmenting  it,  the  module  discards  the  datagram  and 
returns  an  error  to  the  source  IP.  Note  that  fragmentation,  transmission, 
and  reassembly  at  the  subnetwork  layer  is  transparent  to  IP  and  can  be 
used  at  any  time. 

9.2.3  Checksum.  IP  assumes  the  subnetwork  layer  to  be  unreliable  regard¬ 
less  of  the  actual  subnetwork  protocol  present.  Therefore,  IP  provides  a 
checksum  «chanlsm  supporting  the  delivery  service  to  protect  the  IP  header 
from  transmission  errors.  The  data  portion  is  not  covered  by  the  IP  checksum. 
If  IP  enforced  a  data  diecksum  and  discarded  datagrams  with  data  checksum 
failures,  it  could  not  support  applications  that  require  high  throughput  and 
can  tolerate  a  low  error  rate.  An  IP  module  recomputes  the  checksum  each 
time  the  IP  header  Is  changed.  Changes  occur  in  transit  during  tlme-to-llve 
reductions,  option  updates  (both  explained  below),  and  fragmentation.  The 
checksum  is  currently  a  simple  one's  complement  algorithm,  and  experimental 
evidence  indicates  its  adequacy.  However,  the  algorithm  is  provisional  and 
may  be  replaced  by  a  CRC  procedure,  depending  on  future  experience. 

9.2.4  Time-to-live.  As  men^Jioned  in  the  routing  discussion  above,  a 

franaiaiaaton  path  is  Subject  to  changes  in  internet  topology  and 
traffic  coolitiotm.  Inadvertently,  a  datagram  might  be  routed  on  a  circuitous 
path  to  arrive  at  Its  destination  after  a  considerable  delay.  Or,  a  datagram 
could  loop  through  the  same  IP  modules  without  making  real  progress  towards 
its  destination.  Such  "old  datagrams*  reduce  internet  bandwidth  and  waste 
processing  time.  To  prevent  these  problems,  IP  provides  a  mechanism  to 
limit  the  lifetime  of  a  datagram,  called  time-to-llve.  Along  with  the  other 
senlif^  parameteis,  a  ULP  specifies  a  maximum  datagram  lifetime  in  second 
units.  Each  IP  module  on  the  gateway  route  decreases  the  time-to-llve  value 
carried  in  the  IP  header.  If  an  IP  module  receives  an  expired  datagram,  it 
discards  the  datagram.  The  Ufttime  limit  Is  In  effect  until  the  datagram's 
data  is  delivered  to  the  destination  ULP.  That  is,  if  a  datagram  is  frag- 
wnted  during  transmission,  it  can  still  expire  during  the  reassembly  process. 
Section  9. 4. 4. 3  defines  the  reassembly  algorithm  use  of  the  tlme-to-live  data. 

9.2.5  Type  of  service.  In  support  of  the  virtual  network  service,  the 
type  of  service  mechanism  allows  upper  layer  protocols  to  select  the  traim- 
mission  quality.  IP  passes  the  type  of  service  (TOS)  cem^nd  set  for 
service  quality  to  the  SNP  where  it  Is  mapped  into  subnetwork-specific 
transmission  parameters.  Not  eveiy  subnetwork  supports  all  transmission 
services,  but  each  SNP  on  the  delivery  path  should  make  its  best  effort  to 
match  the  available  subnet  services  to  the  desired  service  quality.  The  TOS 
comaarxi  set  includes  precedence  level,  a  delay  indication,  a  throughput 
Indication,  and  a  reliability  indication.  Precedence  is  a  measure  of  a 
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datagraa's  laportance.  A  subaetwork  «ay  treat  high  precedence  traffic  aa 
■ore  laportant  than  other  traffic  by  preferentially  allocating  subnetwork 
resources  especially  during  time  of  high  load*  The  eight  precedence  levels 
begin  with  the  lowest.  Routine,  and  Increase  up  to  the  two  highest  levels. 
Internetwork  Control  aud  Network  Control*  The  highest  precedence  level. 
Network  Control,  Is  Intended  for  use  only  within  a  subnetwork*  The  Internet¬ 
work  Control  level  Is  Intended  for  use  by  gateway  control  originators  only* 

The  actual  use  and  access  to  these  precedence  levels  Is  the  responsibility 
of  each  subnetwork*  Aside  from  precedence,  the  aajor  service  choice  is  s 
three-way  tradeoff  between  low  delay,  high  reliability,  and  high  throughput* 

In  many  networks  better  performance  for  one  of  these  parameters  Is  coupled 
with  worse  performance  for  another*  Except  for  vsry  unusual  cases,  not  more 
than  two  of  these  three  Indications  should  be  set*  The  use  of  these  service 
quality  Indications  may  Increase  the  cost  (In  soma  sense)  of  the  service* 
Section  9*3*15  specifies  the  legal  values  of  the  type  of  service  Indicators 
to  be  carried  In  the  datagram  header. 

9.2*6  Data  options*  Motivated  by  the  virtual  network  service,  IP  provides 
options  to  carry  certain  Identification  and  timing  data  In  a  standard  manner 
through  the  Internet*  The  use  of  this  mechanism  by  the  ULPs  Is  optional,  as 
the  name  Implies,  but  all  options  must  be  supported  by  each  IP  Implement  at  lon« 
The  data  options  carry  three  kinds  of  Information:  security,  stream  Identifi¬ 
cation,  and  timing*  The  security  data  Is  used  by  DoD  hosts  needlug  to  trans¬ 
mit  security  Information  throughoiit  the  Internet  In  a  standard  manner*  The 
security  Information  (required  If  classified,  restricted,  or  eompartmanted 
traffic  Is  passed)  Includes  security  level,  compartments,  handling  restric¬ 
tions,  and  transmission  control  code*  The  stream  Identification  option 
provides  a  way  for  a  stream  Identifier  to  be  carried  both  through  stream- 
oriented  subnetworks,  for  example  SATNBT,  and  subneta  not  supporting  the 
stream  concept* 

9*2*6*  1  Timing  Information*  Timing  Infozmatlon,  In  the  fon  of  timestamps, 
la  recorded  by  IP  modules  as  the  datagram  traverses  the  Internetwork  to  Its 
destination*  The  aoutce  ULP  provides  a  timestamp  list  and  Indicates  timing 
Information  Is  to  be  recorded.  The  timestamp  can  be  recorded  In  one  of 
three  formats*  The  first  format  requires  each  gateway  IP  module  on  the 
gateway  route  to  register  only  Its  timestamp  in  rhe  next  free  list  entry. 

The  second  format  i^ulres  each  gateway  IP  to  reglsK^t  tnh  Its  Internet 
address  and  Its  timestamp.  The  third  format  requires  a  to  be 

registered  only  If  the  next  list  entry  containing  a  prespeelfleo 
address  matches  the  gateway  IP's  address.  These  formats  are  specified  in 
section  9.2.15*  A  tlmestmip  Is  a  32-blt  value  marking  the  current  time  in 
mllUaeconds  since  midnight  Dnlversal  Tims  (UT).  If  the  time  Is  not  available 
in  mllUseconds,  or  cannot  be  provided  with  respect  to  DT,  then  any 

time  may  be  Inserted  If  the  high  order  bit  of  the  timestamp  flSAo  to 

one,  Indicating  the  use  of  a  non-standard  value*  Vhen  using  the  timestamp 
option,  the  source  ULP  must  provide  a  large  enough  list  to  accommodate  ell 
the  timestamp  Information  expected.  The  siae  of  the  option  does  not  change 
due  to  adding  timestamps*  Ths  Initial  contenta  of  ths  tlmastamp  list  must  be 
ssro  or  Internet  sddrssa/ssro  pairs.  If  ths  timestamp  date  arts  la  already 
full  (ths  pointer  sxcssds  ths  length)  ths  datagram  la  forwarded  without 


30 


MILITARY  STANDARDS:  IP 


MIL-STD  1777 


MIL-STD-1777 
12  August  1983 


Inserting  the  tinestaap,  but  the  overflow  count  Is  increnented  by  one*  If 
there  Is  soae  rooa  but  not  enough  for  a  full  tlaestaap  to  be  Inserted,  or 
the  overflow  count  Itself  overflows,  the  original  datagran  Is  considered 
to  be  In  error  and  Is  discarded*  In  either  case,  an  ICMP  paraaeter  problen 
■essage  may  be  sent  to  the  source  hoot*  Errors  encountered  by  the  gateway 
IPs  during  tlaestaap  processing  are  reported  to  the  source  IP* 

9*2*7  Error  report  datagraas*  The  error  reporting  service  aotlvates  a 
aechanlsa  to  generate  and  process  error  Infoiaatlon*  The  error  aechanlsa 
uses  the  datagraa  delivery  service  to  transfer  the  error  reports  between  IP 
aodules* 

9*3  Message  t  for  peer  exchanges*  A  suoaery  of  the  contents  of  the 
IP  header  follows*  ^ote  that  each  tl»  aark  represents  a  one  bit  position* 
Each  field  description  below  Includes  Its  naae,  an  abbreviation,  and  the 
field  sice*  Where  applicable,  the  units,  the  legal  range  of  values,  and  a 
default  value  appears* 
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9*3*1  Version* 

abbrev:  VER  field  else:  4  bits 

The  Version  field  indicates  the  foraat  of  the  IP  header*  This  docuaent 
describes  version  4, 

9.3*2  internet  header  length. 

abbrev:  IKL  field  else:  4  bits 

units:  4-octet  group  range:  S  -  IS  default:  S 

Internet  Header  Length  is  the  length  of  the  IP  header  in  32-blt  words  and 
to  the  beginning  of  the  data*  Note  that  the  alnlKia  value  for  a 
correct  h:eder  Is  S* 
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9,3,3  Type  of  service, 

abbrev:  TOS  field  alse:  8  bits 

The  Type  of  Service  field  contains  the  IP  paraneters  describing  the  quality 
of  service  desired  for  this  datagrae, 

0  1  2  3  4  B  s  7 
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Bits  0-2:  Precedence 

Bit  3;  Delay 

Bits  4:  Throughput 

Bits  5:  Reliability 

Bit  6-7:  Reserved  for  Future  Use, 

Delay 

0  -  nomal 
I  -  low 

Throughput 
0  -  noresl 
1  -  high 

Reliability 
0  -  norval 
1  -  high 

FinURE  7 ,  Table  of  service  field. 


9.3.4  Total  length. 

abbrev:  Tl,  field  sixc:  16  bits 

units:  octets  range:  20  -  2**16-1  default:  20 

Total  Length  l«  the  length  of  the  datagraa.  Measured  in  octets,  including 
header  pr^rtfo.  nnd  the  data  portion  of  the  datagraa. 

5 , 3 . ^  Idertif ication. 

abbrev:  ID  field  sise:  16  hits 

An  Idcniltylug  value  used  to  associate  fragaents  of  a  datagraa.  This  value 
is  usually  supplied  by  the  sending  ULP  aa  an  interface  poraactcr*  If  not, 

IP  getierates  lUtagraw  Identifications  tdilch  are  unique  for  etch  aendlng  ULP. 


Precedence: 

111  -  Network  Control 
ilO  -  Internetwork  Control 
101  -  CRITIC/ECP 
100  -  Flash  Override 
oil  -  FUsh 

010  -  laaedlace 
001  ~  Priority 
000  -  Routine 
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9.3.6 


sbbrsv:  uons  field  tlx®:  3  bits 

This  field  contslos  the  control  flags  "don’t  fragment,"  idilch  prohibits 
IP  fragaentatlon  and,  "aore  fragaents,"  which  helps  to  identify  a  fragment  s 
position  in  the  original  datagraa. 
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0 

M 
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F 

F 

Bit  0:  reserved,  aust  be  sero 

Bit  1;  (DF)  0  -  May  Pragasnt,  1  -  Don’t  Fragaant, 
Bit  2:  (MF)  0  -  Last  Fragasut,  I  -  More  Fragaants. 

FIGURE  8.  Control  flags  field. 


9.3.7  Fragaent  offset. 

abbrev;  FO  fiald  else:  13  bits 

units:  8-octet  groups  rangs:  0  -  8191  default:  0 

This  field  indicates  the  positions  of  this  fragaant's  data  relative  to  the 
begioniug  of  the  data  carried  In  the  original  datagram.  Both  a  complete 
datagraa  at^  a  first  fragaent  have  this  field  set  to  sero.  Section  9.2.2 
describes  the  fragasntatlon  aedianisa. 

9.3.8  Tiae-to-Uve. 

sbbrev:  TTL  field  sUe:  8  bits 

units:  seconds  rangs:  0  -  255 (*8*25  mine)  default:  15 

This  field  indicates  tlie  aaxlaua  time  the  datagraa  is  allowed  to  remain  In 
the  internet.  If  the  valnt  of  this  field  drops  to  sero,  the  datagraa  should 
be  destroyed.  Section  9.2.8  describes  the  tlae-to-llve  mechanism. 

9.3.9  Protocol. 


abbrev:  PIOT  field  sUe:  8  bits 

This  field  Indicates  which  ULP  Is  to  receive  the  data  portion  of  the  dutigraa. 
The  leiabem  assigned  to  coaaon  ULPs  are  avaiable  from  the  DoO  Executive 
Agent  for  Protocols. 

9.3.10  Header  checksum. 


abbrev:  none  field  sise:  18  bits 
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This  flsld  coatsios  the  checksum  covering  the  IP  hesder.  The  checksum 
■echsnlsm  Is  described  In  section  9* 2. 3. 

9.3.11  Source  address* 

sbbrev:  source  field  else:  32  bits 

This  field  contslns  the  Internet  address  of  the  detsgrem's  source  host. 
Internet  address  formats  are  discussed  In  section  9.2.1 • 

9.3.12  Destination  address. 

abbrfv:  dest  field  else:  32  bits 


This  field  contains  the  Internet  address  of  the  datagram's  destination 
host.  Internet  address  formats  are  discussed  In  section  9.2.1. 

9.3.13  (^tlons. 

sbbrev:  none  field  else:  variable 

The  option  field  Is  variable  In  length  depending  on  the  number  and  types  of 
options  associated  vlth  the  datsgram*  The  options  mechanisms  are  discussed 
In  sections  9.2.1  and  9.2.6.  Options  have  two  formats: 

a.  a  single  octet  of  option-type,  or 

b.  a  variable  length  string  containing: 

1.  an  option-type  octet, 

2.  an  option-length  octet  *  counting  the  option-type  octet  and 
option- length  octet  as  well  as  the  option-data  octets,  and 

3.  the  actual  option-data  octets. 


The  option-type  octet  Is  viewed  as  having  3  fields: 


bit  0  -  copy  flag 

0  •  not  copied,  I  •  copied 
blta  1-2  -  option  class 

000  •  control 

001  •  reserved  for  future  use 
010  •  debugging  and  measurement 
Oil  -  reserved  for  future  use 
bits  3-7  -  option  number  (defined  In  the  following  table) 


PICURC  9,  Fields  in  the  option-type  octet. 
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9. 3. 13.1  Infrntt  options  dt fined >.  Th«  follovlng  Internet  optlor^  ere 
defined: 

CLASS  NUMBER  IZHGIH  DESCRIPTION 

0  0000  End  of  Option  list:  This  option  occupies 

only  1  octet;  It  has  no  length  octet. 

0  00001  -  No  Operation:  This  option  occupies  only  1 

octet;  It  has  no  length  octet. 

0  00010  U  Security:  Used  to  carry  security  level, 

Coapar^aentatlon,  User  Group  (TCC),  and 
Handling  Restriction  Codes  conpatlble  with 
DoO  requirement a. 

0  00011  var.  Loose  Source  Routing:  Used  to  route  the 

datagraa  based  on  Infomatlon  supplied  by 
the  source. 

0  01001  var.  Strict  Source  Routing:  Used  to  route  the 

datagraa  based  on  Information  supplied  by 
the  source. 

0  00111  var.  Record  Route:  Used  to  trace  the  route  a 

datagraa  takes. 

0  01000  4  Stream  10:  Used  to  carry  the  streaa 

Identifier. 

2  00100  var.  Internet  Tlaestaap:  Used  to  accuaulate  timing 

Information  In  transit. 

9.3.14  Padding. 

abbrevt  sons  field  stss:  varlabU  (8  to  24  bits) 

The  IP  header  padding  la  used  to  ensure  that  the  IP  header  ends  on  a 
32-blt  boundary.  The  padding  field  Is  set  to  aero. 

9.3.15  Specific  option  definitions.  Bach  option  format  is  defined  below. 
"Option  type’  Indicates  the  value  of  the  option-type  octet,  and  "length" 
Indicates  the  value  of  the  length-octet  if  appropriate. 

9.3.15.1  End  of  option  list. 

option  type:  0  option  length:  N/A 

This  one-octet  option  marks  the  end  of  the  option  list  vtien  It  does  not 
coincide  with  the  four-octet  boundary  indicated  by  the  IP  header  Ui^th. 

This  field  is  used  following  the  laet  option,  not  the  end  of  each  option, 
and  need  only  be  used  if  the  last  option  would  not  otherwise  coincide  with 
the  end  of  the  IP  header.  This  option  may  be  introduced  or  deleted  upon 
fragmentation  as  needed. 
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9. 3* 15 .2  No  operstlon* 

option  typt:  1  option  Isngth:  N/A 

This  option  asy  be  used  betveen  options,  for  exeaple.  to  slign  the  beginning 
of  s  subsequent  option  on  s  32-bit  bounds ry.  This  option  asy  be  introduced 
or  deleted  upoo  frsgaentstion  so  needed. 

9.3.15.3  Security. 

option  type:  130  option  Isngth:  11 

This  option  (required  if  clsssified.  restricted*  or  coapsrtasnted  trsffic  is 
psssed)  provides  s  way  for  hosts  to  send  Security  level.  Coapsrtaentstion. 
Hsndling  F.estrictioD  Codes  snd  User  Groups  (TCC)  psrsaeters  through  subnet- 
works  in  t  otsndsrd  asnner.  This  option  aust  be  copied  on  frsgasntstioo. 
This  option  sppests  st  aost  once  in  s  dstsgrsa. 

The  focast  for  this  option  is  es  follovs: 


10000010 

09001011 

ccc  ccc 

— — 1 

- - 

1 - /A_l 

1 — 

TYSC  «  130  LESQTH  •  11 


FI cuts  10.  Security  Option  Forast* 

9.3.15.3.1  Security  (S  field). 

length:  16  bits 

This  field  specifies  one  of  16  levels  of  security,  eight  of  idiieh  ere  reserved 
for  future  use. 


00000000  00000000 
11110001  00110101 
OllltOOO  lOOUOlO 
10111100  01001101 
01011110  OOlOCllO 
10101111  00010011 
11010111  10001000 
01101011  11000101 
00110101  11100010 
10011010  11110001 
01001101  01111000 
00100100  10111101 
00010011  01011110 
10001001  10101111 


-  Unelssaified 

-  Coafldentisl 

-  EFTO 

-  KMIM 

-  PROG 

-  Restricted 

-  Secret 

-  Top  Secret 

-  (Reserved  for 

-  (Reserved  for 

-  (Reserved  for 

-  (Reserved  for 

-  (Reserved  for 

-  (Reserved  for 


future  use) 
future  use) 
future  use) 
future  use) 
future  use) 
future  use) 


36 


1-110 


MILITARY  STANDARDS:  IP 


MIL-STD  1777 


HXL-STD-X??? 
U  Avtgutt  I9a3 


11000100  11010110  *  (tcMCvtd  for  futuro  um) 

IIIDOOIO  OIIOIOII  •  (Ronorrod  for  futuro  uM) 

9.3.15.3.2  CoTOort— nti  (C  fiold)* 
longth  ■  16  Mti 

This  fiold  eontolw  oa  all  caro  aalua  vhaa  tho  iaforaatloa  traaaaltead  la 
aot  conpartMatad.  Othar  voluaa  for  tha  coapartaaata  fiald  aay  ba  obtainad 
froa  tba  Dafaaaa  Intalllgaaca  Agaaqr  (DU). 

9.3.15.3.3  Handliai  raatrictioaa  (H  fiald). 
laagth  •  16  bita 

Tha  aaliiaa  for  tha  control  and  ralaaaa  aarklnga  ara  alphaaiMrle  digrapha 
and  ara  daflaad  la  tha  Dafaaaa  latallipaea  Agiaey  Manual  DIAM  6;i-19, 
^Standard  Saeurlty  Marklnga.” 

9.3.15.3.A  Tranaalaalon  control  coda  (TCC  fiald). 

laagth  «  24  blta 

Thl^  fiald  provldaa  a  aaaia  to  aagragata  traffic  and  daflna  coatrollad 
coHBualtlaa  of  lataraat  aaoag  aubacrlbara.  Tha  ICC  valuaa  ara  trlgraphs  and 
ara  arallabla  froa  laadquartactt  DCA  (Coda  530). 

9.3.15.4  Looaa  aourca  aad  racord  routa* 

option  typa:  131  option  langthi  rarlabla 

Tba  looaa  aourca  routa  option  provldaa  a  any  for  tha  aourca  OLF  of  a 
datagraa  to  aupply  routing  Iaforaatloa  to  ba  uaad  by  IF  aodulaa  along  tha 
ptavay  routa.  At  tha  aaaa  tlaa,  tha  *lnuarta*  routa  la  racerdad  In  tha 
option  fiald.  Thla  option  la  not  coplad  on  fragaaatatloa.  It  appaara  at 
aoat  oaca  la  a  datagraa.  Tha  option  baglna  with  tha  option  typa  coda.  Tha 
aacond  octat  la  tha  option  langth  which  includaa  tha  option  typa  octat*  tha 
laagth  octat,  tha  polntar  octat,  and  tha  aourca  routa  Uat.  Tha  third  octat 
la  a  polntar  Into  tha  routa  dhta  Indicating  tha  octat  which  baglna  tha  naxt 
aourca  addraaa  to  ba  procaaaad.  Tha  polntar  la  ralttlwo  to  thla  option,  and 
Ita  anallaat  lagal  wilua  la  4.  A  looaa  aourca  routa  Hat  la  conpoaad  of  ooa 
or  nora  Intamat  addraaaaa  Idantlfylng  Intamadlata  gatawaya  to  ba  vlaltad 
In  tranalt.  Inch  Intamat  addraaa  la  4  octata  long.  Vhan  a  gat«fny  In  tha 
aourca  routa  Uat  la  vlaltad,  tha  gataway  addraaa  (aa  known  In  tha  anvlroo- 
■ant  Into  which  tha  datagraai  la  balng  forwarded)  raplacaa  that  Hat  entry. 
Tha  alaa  of  thla  option  la  fixed  by  tha  aourca.  It  eannoc  change  to  acco«* 
mdata  additional  lofomatlon.  Tha  routing  optlona  ara  daacrlbad  In  aactlon 
9.2.I.I. 
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9«3.1S»5  Strict  sourcs  and  rscord  routs » 

option  tjpt:  137  option  length:  varisbls 

The  strict  source  route  option  provides  e  vey  for  ths  source  ULP  of  a  dsts- 
grsB  to  naas  the  exact  set  of  IP  nodules  to  be  visited  along  the  gateway 
route.  At  the  aaa*  tlissi  t>te  "inverse*  routv.  is  recorded  in  the  option 
field.  This  option  «ust  be  copied  on  fragaen<;;ation.  It  appears  at  aost 
ones  in  a  datagraa.  The  option  begins  with  the  option  type  code.  Ths  second 
octet  is  the  option  length  idiich  includes  the  option  type  octet,  the  length 
octet,  the  pointer  octet,  and  the  source  route  list.  The  third  octet  is  a 
pointer  into  the  route  data  indicating  the  octet  ehich  begins  the  next  source 
address  to  be  processed.  Ths  pointer  is  relative  to  this  option,  and  its 
saallest  legal  value  is  4,  A  strict  source  route  list  is  coaposed  of  one  or 
nore  internet  addresses  identifying  the  gateways  to  be  visited  in  transit. 

The  datagraa  aust  visit  exactly  the  gsteways  listed,  traversing  only  the 
directly  connected  subnetwoxks  indicated  in  the  route  list  sddresses.  Vhsn 
a  gateway  in  the  source  route  list  is  visited,  the  gateway  address  (as  known 
in  the  envirooMnt  into  which  the  datagraa  is  being  forwarded)  replaces  that 
list  entry.  The  site  of  this  option  is  fixed  by  the  source.  It  cannot  change 
to  accoaaodate  additional  infoiaation.  Routing  options  are  described  in 
section  9.2. 1.1. 

9.3.15.6  Record  route. 


option  type:  7  option  length:  variable 

The  record  route  option  provides  a  way  to  record  s  datagraa* s  gateway  route. 
This  option  is  not  copied  on  fragasntation.  It  appears  at  aost  once  in  a 
datagraa.  The  option  begins  with  the  option  type  code.  The  second  octet  is 
the  option  length  which  includes  the  option  type  code,  the  length  octet, 
and  the  return  route  list.  The  third  octet  is  a  pointer  into  the  route  data 
indicating  the  octet  which  begins  ths  neat  area  to  store  a  route  address. 

The  pointer  is  relative  to  this  option,  and  the  saallest  legal  value  for 
the  pointer  is  4,  A  record  route  list  is  coaposed  of  a  series  of  Internet 
addresses.  Each  internet  address  is  4  octets  long.  The  source  VLF  provides 
a  route  list  with  sero  value  entries.  As  each  gateway  is  visited  in  transit, 
it  registers  its  address  In  the  next  free  entry  (indicated  by  the  pointer). 
When  the  pointer  is  greater  than  the  length,  the  record  route  list  is  full. 

Re  eddit tonal  addressss  are  recorded,  even  if  aore  are  visited  before 
arriving  at  the  destination.  The  slae  of  this  option  is  fixed  by  the  source. 
It  cannot  change  to  accoaaodate  additional  Infonsation.  Ths  routing  options 
are  described  in  section  9.2. 1.1. 

9.3.15.7  Streaa  Identifier. 


option  type:  136  option  length:  4 

This  option  provides  a  way  for  l6-'blt  streaa  Identifiers  to  be  carried  through 
the  Internet  for  use  br  eubnetworVe  supporting  the  streaa  concept  such  as 
the  SAIRET.  The  stress  identifier  appean  In  the  third  and  fourth  octets  of 
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tht  option.  This  option  aust  bs  coplsd  on  frsgasntstlon.  It  sppsscs  st 
■ost  ones  in  s  dstsgrsa. 

9.3.1S.8  Intsrnst  tiasstsap. 

option  typs:  68  option  Isngth:  ▼srlsbU 

This  option  sllouB  tlalng  Inforastlon  to  bs  gsthsrsd  ss  s  dstsgrsa  trsvsis 
through  ths  Intsmst  to  Its  dost  Inst  ton.  This  option  Is  not  coplsd  upon 
frsgwntsclon  snd  so  sppssrs  only  In  ths  first  frsgasnt.  This  option  asy 
sppssr  St  most  ones  In  s  dstsgrsa.  Ths  first  octst  Is  ths  option  typs.  Ths 
sscond  octst  Is  ths  Isngth  of  ths  option  Including  ths  option  typs  octst, 
ths  Ist^th  octst,  the  pointer  octst,  the  ossrf loa/flsg  octet,  snd  ssch  tlas- 
stsap  or  sddrsss/tlasstsap  pslr.  Ths  third  octst  Is  s  pointer  into  ths 
tlasstsBp  list  identifying  ths  octet  beginning  ths  specs  for  the  ns*t  tlas^ 
etsap.  Ths  pointer  Is  rslstlvs  to  the  beginning  of  this  option;  Its  saellcst 
Isgsl  value  Is  5.  The  fourth  octet  Is  shersd  by  overflow  snd  forast  fUg 
Inforastlon.  Ths  first  four  bits  record  ths  nuaber  of  IP  nodules  thst  could 
not  ri^lstsr  tlasstsaps  due  to  Inch  of  specs.  The  second  four  bits  Indlcsts 
ths  forast  of  ths  tlnestsap  list: 

0  tlasstasps  only,  stored  In  consecutive  3Z*blt  words 

1  *  ssch  tlnestsap  Is  preceded  with  the  Intsmst  sddress 

of  the  registering  entity 

2  *  reserved  for  future  use 

3  -  ths  Internet  sddress  fields  srs  prespsclflsd  by  ths 

source  OUP.  An  IP  nodule  only  rsglotsts  its  tlassts^^ 

If  Its  address  astchss  the  next  one  In  ths  list. 

Ths  site  of  this  option  Is  fixed  by  ths  source.  It  esnnot  change  to  sccea* 
a>dste  additional  Inforastion.  Ths  Intsmst  tinsstasp  option  Is  described 
In  section  9.2.6. 

9.6  Extended  ststv  aschins  specification  of  IP  entity.  Ths  IP  entity  Is 
specified  with  an  extended  state  aschlne  asds  up  of  a  set  of  states,  a  set 
of  crawltloia  hetweeu  states,  and  a  set  of  Input  events  causing  the  state 
transitions.  The  following  specification  Is  asds  up  ^  a  aschlne  Instantia¬ 
tion  identifier,  a  state  dlagraa,  a  state  vector,  data  structures,  an 
event  list,  and  a  correapondsnee  between  events  and  actions.  In  addition, 
an  extended  state  aschlne  has  an  initial  state  whose  values  are  assuaed  at 
state  aachine  iostantiatlon. 

9.4.1  Machine  instantiation  identifier.  Eacf  datagraa  la  an  Independent 
urit.  Therel^cre,  one  state  asdiine  instance  exists  for  each  datagraa.  Each 
state  aachine  is  uaiquely  naaed  by  the  four  values,  source  address,  destina¬ 
tion  address,  protocol,  and  Identification.  These  values  are  drawn  froa 
par^stscs  of  rhs  interaction  ,  rlaltives  specified  in  sections  6.2  and  8.2. 

9.4.2  State  dlagraa.  The  fo!  ^wlng  dlagraa  depicts  a  slapltfled  IP  state 
aachine. 
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Sf NO  on  SfCf ivf 

A  COMnrTE  DATAGRAM 


HkCI'Vf 
f'  *:7 


trCflvE  COAiniTE  DATAGRAM, 
on  fINAl  rRAQMFNT. 

OR  RtASSEMSLV  TIME  GUI 


RfCfIVF  FRAOMENfS 


FlCURli  1  i ,  A  sln>llflRd  IP  stAts  tehlBt* 

9. A.  3  Ststt  vctot.  A  Stitt  wtctor  consists  of  tht  folloirlnf  tltasots: 

-  STATE  HAKE  •  (Inivtivt,  r«isstait!Zng) 

•  ItEASSEKiLY  EE80UICSS  •  control  Inf  omit  ion  ind  s  tongs  nttdtd  to 
rtisstable  frifasnts  Into  the  originil  ditigriB,  Includlnc: 

1.  rtisstu^ly  aip:  i  nprtssntitlon  of  tich  8*octtt  unit  of 
dsti  snd  Its  rcliiiv«  locstlon  vltKTn  tht  orletnAl  ^ifsgriNtt 

b.  tiner:  nlui  of  the  rcissently  tlaer  In  unit  seconds  froa 
0  to  235. 


c.  totil  dsts  length:  sixe  ox  the  deti  cirritd  in  dst^^Ersai 
bt'.ng  rtisseabltd. 

d.  hs«<er:  stonge  ires  for  the  htsdtr  portion  of  the  ditigri 
being  rtissei^led. 


«.  dits;  Stonge  irei  for  ttic  dita  portion  of  the  dstigna 
being  reinsenbled. 

A  st«t«^  nichlne's  Initial  state  is  IHACTIVE  with  unused  reasstably  resources* 

9.4.4  Data  structures.  The  If  statr  taschine  references  certain  data  areas 
correapondlng  to  the  slate  vector,  atv!  each  interaction  primitive: 

OELIVEK,  SKfjSEKD  and  SHf^CNELlVEE.  For  clarity  in  the  eventa  and  actlona 
section,  data  atructuras  are  decUred  lu  Ads  for  theae  data  areas.  Mowevar. 
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a  data  structure  may  be  partially  typed  or  completely  untyped  where  specific 
formats  or  data  types  are  implementation  dependent* 

9.4*4. 1  State  vector.  The  definition  of  an  IP  state  vector  appears  in 
section  9.4.3  above.  A  state^vector  structure  is  declared  as: 

state^vector:  8tate__vector_typc; 

type  state_vectorjtype  is 
record 

state^name:  (INACTIVE.  REASSEMBLING); 

reassemblyjaap 

timer 

total_data_length 

header 

data 

end  record; 

9. 4. 4. 2  Prom  ULP.  The  from  ULP  structure  holds  the  Interface  para^ters 
and  data  associated  with  the  SEND  primitive,  as  specified  in  section  6.2.1. 
The  fromJJLP  structure  is  declared  as: 

fromJJL?:  fromJJLP_type; 

type  fromJJLP^type  is 
record 

sourcejiddr 

dee t inat ion^addr 

protocol 

type_of_servin»  is 
record 

precedence 
delay 
throughput 
reUabiUty 
end  record; 

identifier  tlma_to_live 
do..J_*L’agment 
length 
data 
options 
end  record; 

9. 4. 4. 3  To  ULP.  The  toJJLP  structure  holds  Interface  parameters  and  data 
associated  with  the  DELIVER  primitive,  as  specified  in  section  6.2.2.  The 
toJJLP  structure  is  declared  as: 

toJJLP  :  toJJLP^type; 

type  toJJLP^type  is 
record 

source  ad dr 
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de  1 1  ins  t  lonjid  dr 
protocol 

type_of__servlce  is 
record 

precedence 
deliy 
throughput 
rellebillty 
end  record; 
length 
lists 
options 
error 

end  record; 

9*4 .4 .4  Fros  SNP<i  The  froa^SNP  structure  holds  the  interfsce  psrsaeters 
end  dstsgrss  sssoci'sted  with  the  SNP^DELIVER  primitive »  ss  specified  In 
section  8*3 .2.  The  froa^SNP  structure  Is  declsred  ss: 

type  froB_SNP_type  Is 
record 

Iocs  l_^des  t  Inst  lonjsd  dr 
dtgn:  dstsgrsa^type; 
error 

end  record; 

The  dtgs  eleaent  Is  Itself  s  structure  ss  specified  below, 

9«4,4«5  To  SKP,  The  to_^SNF  structure  holds  the  dsts  end  psrsasters 
ssioelsted  with  the  SKP_SEND  primitive  specified  In  section  8,3.1.  The 
to_^SItP  structure  Is  declsred  ss: 

type  to_SNP_type  Is 
record 

lo es  l_de s t Ins t lonjsd dr 
type^of__servlce^lndlcs  tot  c 
length  ~ 

dtgii:  dstsgrse^typc; 
end  record; 

The  dtge  clement  Is  Itself  s  structure  ss  specified  belo:i. 

9. 4,4,6  Dtgm.  A  dtge  structure  holds  s  dstsgrse  esde  up  of  s  hesder 
portion  snd  s  dsts  portion  ss  specified  In  section  9.3.  A  dtge  structure 
Is  declsred  ss: 

type  dstsgrse_type  Is 
record 

version:  HALFJOCTET; 
heeds r^length:*^  HALFJOCTET; 
type^of^service:  OCTET; 
totsi^length:  TWOJOCTETS; 
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Ident if lea t ion  s  TWOJJCTETS ; 
dont^f  rag^f  lag :  BOOLEAN ; 

■ora""  frag__£lag:  BOOLEAN; 

fragSent  offset:  ONEJi_FIVE_EIGHTHSJ)CTETS; 
t  liM^toJIl  ve :  OCrET;^ 
protocol:  OCTET; 
header^checkaua:  TWO^pCTETS; 
source  ad dr:  P0URJ3CTETS; 
destlnatlon^addr:  FOUR^OCTETS; 
opt  Iona:  OPTIONJTPE; 
data:  array(l*  •DATA^USNGTH)  of  INTE®R; 
end  record; 

subrecord  HALFJKTTET  is  INTEGER  range  0,.15; 
subrecord  OCTET  is  INTEGER  range  0..255; 

aubrecord  ONE  N_FIVE  EIGHTHSJXnETS  is  INTEGER  range  0..8191; 
subrecord  TWO““oan£TS“is  INTEGER  range  0.  .65535; 
subrecord  FOUR  OCTETS  is  INTEGER  range  0. .4294967296; 
subrecord  OPTIONJKPE  is  sero  or  wove  of  the  following: 

*“  security; 

loose  source  routing; 
strict  source  routing; 
record  route; 
streaa  identifier; 
internet  tines tanp; 

9.4.5  Event  list.  The  event  list  is  made  up  of  the  interaction  prinl- 
tives  specified  in  sections  6.2  and  8.2  and  the  services  provided  by  the 
execution  environ^nt  defined  in  section  10.  The  following  list  defines 
the  set  of  possible  events  in  an  IF  state  machine: 

a.  SEND  from  DLP  —  A  ULP  passes  Interface  parameters  and  data 
to  IP  for  delivery  across  the  internet  (see  section  6. 2.1.0* 

b.  SNPJ)ELIVER  from  SNP  —  SNP  passes  to  IP  a  datagram  received 
from  subnetwork  protocol  (see  section  8. 2. 2.0* 

c.  TIMEOUT  —  The  tinii^  mechanism  provldtsd  by  the  execution 
envlroiMent  irdicatea  a  previously  specified  time  interval  has 
elapsed  (see  section  10.3). 

0,4,^  Events  and  actions.  This  section  is  organUed  In  chr“e  parts.  The 
f  rat  part  contains  a  decision  table  representation  of  state  machine  events 
ard  r.ctiom.  The  decision  tables  are  organised  by  state;  each  table  corre¬ 
sponds  to  one  event.  The  second  part  specifies  the  decision  functions 
appearing  at  Che  top  of  each  column  of  a  decision  table.  These  functions 
examine  attributes  of  the  event  and  the  state  vector  to  return  a  set  of 
decision  results.  The  results  become  the  elements  of  each  column.  The  third 
part  specifies  action  procedures  appearing  at  the  right  of  every  row.  Each 
row  of  the  decision  table  combines  the  decision  results  to  determine  appro¬ 
priate  event  processing.  These  procedures  specify  event  processing  algorithms 

in  detail. 
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9.4.6. 1  Events  and  actions  decision  tables. 

9. 4. 6. 1.1  State  ■  inactive,  event  is  SEND  froa  UIJP. 

TABLE  I,  Inactive  state  decision  table  when  event  la  SEND  fro»  ULP. 
Actions: 


ULP 

PARAMS 

VALID? 

WHERE 

DEST 

? 

NEED 

TO 

FRAG? 

CAN 

FRAG 

? 

NO 

d 

d 

d 

ERROR  TO  ULP  IPARAM^PROSLEMI 

YES 

ULP 

d 

d 

LOCAL  DELIVERY 

YES 

REMOTE 

NO 

d 

BUILD  a  SEND 

YES 

REMOTE 

YES 

NO 

ERROR  TO  ULP  ICAN'T.FRAG) 

YES 

REMOTE 

YES 

YES 

FRAGMENT  4  SEND 

Comoents: 

A  ULP  passes  data  to  IP  for  internet  delivery.  IP  validates  the  Interface 
paraneters,  determines  the  destination »  and  dispatches  the  ULP  data  to  Its 
destination. 

Legend 

d  •  “don't  care"  condition 

9. 4. 6, 1.2  State  ■  Inactive,  event  Is  SWP  DELIVER  from  SUP. 

TABLE  II,  Inactive  state  decision  table  when  event  Is  SNP  PELIVER  from  SHP, 
Act  Ions: 


CHECK¬ 

SUM 

VALID? 

SNP 

PARAMS 

VALID? 

TTL 

VALID 

? 

WHERE 

TO 

? 

A 

FRAG 

? 

ICMP 

CHECK¬ 

SUM? 

NO 

d 

d 

d 

d 

d 

DISCARD 

YES 

NO 

d 

d 

d 

d 

ERROR  TO  SOURCE  (PARAM.PROBUMI 

YES 

YES 

NO 

d 

d 

d 

ERROR  TO  SOURCE  lEXPIRED.TTL) 

YES 

YES 

YES 

ULP 

NO 

d 

REMOTE  DELIVERY 

YES 

YES 

YES 

ULP 

YES 

d 

REASSEMBLE:  STATE;  »  REASSEMBLINO 

YES 

YES 

YES 

ICMP 

NO 

NO 

DISCARD 

YES 

YES 

YES 

ICMP 

NO 

YES 

ANALYZE 

YES 

YES 

ICMP 

YES 

d 

REASSEMBLE:  STATE;  •  REASSEMBLINO 

YES 

YES 

YES 

REMOTE 

d 

d 

ERROR  TO  SOURCE  (HOST_ UNREACH) 
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Cooments: 

The  SNP  hes  delivered  a  datagraa  fraa  another  IP.  IP  validates  the  data-- 
gram  header,  and  either  delivers  the  data  from  a  complete  datagram  to  Its 
destination  within  the  host  or  begins  reassembly  for  a  datagram  fragment. 


don't  care"  condition 


9.4.6. 1.3  State  ■  reassembling,  event  Is  SNP  DELIVER  from  SNP. 


TABLE  III.  Reassembling  state  decision  table  when  event  Is  SNP  DELIVER 
irom  SNP. 


Actions: 


CHECK¬ 

SUM 

VALID? 

SNS 

PARAM8 

VALID? 

TTL 

VALID 

? 

WHERE 

TO 

? 

A 

FRAQ 

? 

REASS 

DONE 

? 

ICMP 

CHECK¬ 

SUM? 

NO 

d 

d 

d 

d 

d 

d 

DISCARD 

YES 

NO 

d 

d 

d 

d 

d 

ERROR_.TO_SOURCE  (PARAM_PROBLEM| 

YES 

YES 

NO 

d 

d 

d 

d 

ERROR_TO_SOURCE  IEXP!RED_TTLI 

YES 

YES 

YES 

ULF 

NO 

d 

d 

REMOTE_DELIVERY:  STATE:  -  INACTIVE 

YES 

YES 

YES 

ULP 

YES 

NO 

d 

REASSEMSLE 

YES 

YE& 

YES 

ULP 

YES 

YES 

d 

REASS.DELIVERY:  STATE:  -  INACTIVE 

YES 

YES 

YES 

tCMP 

NO 

d 

NO 

DISCARD 

YES 

YES 

YES 

ICMP 

NO 

d 

■gm 

ANALYZE:  STATE:  -  INACTIVE 

YES 

YES 

YES 

ICMP 

YES 

NO 

d 

REASSEMBLE 

YES 

YES 

YES 

REMOTE 

d 

d 

d 

ERROR_TO„SOURCE  (HOST_UNREACH| 

Comments: 

The  SNP  has  delivered  de,tagram  associated  with  an  earlier  received  data¬ 
gram  fragment.  IP  validates  the  header  and  either  continues  the  reassembly 
process  with  the  datagram  fragment  or  delivers  the  data  from  the  completed 
datagram  to  Its  destination  within  the  host. 

Legend 

d  •  “don't  care"  condition 
9.4.6. 1.4  State  ■  Inactive,  event  Is  TIMEOUT. 

Act  lone:  reassembly  timeout;  state:  •  IliACTIVE 
Comment: 

The  tlme-to-llve  period  of  the  datagraa  being  reaspembled  has  elapsed. 

The  Incomplete  datagraa  Is  discarded;  the  source  IP  is  Informed. 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


MIL-STD-1777 
12  August  1983 


9*4 *6 *2  Decision  tsble  functiops«  The  following  functions  exenine  inf or* 
■St ion  contained  in  interface  paraneters,  interface  data,  and  the  state 
vector  to  sake  decisions.  These  decisions  can  be  thought  of  as  further 
refineaents  of  the  event  and/or  state.  The  return  values  of  the  functions 
represent  decisions  nade.  The  decision  functiow  appear  in  alphabetical 
order. 


9.4 .6 .2.1  A  frag?  The  ajfrag  function  examines  certain  fields  in  an 
Incoaing  datagraa’s  header  to  detendne  whether  the  datagran  is  a  fragwnt 
of  a  larger  datagraa.  The  data  effecta  of  this  algoritha  are: 

a.  Data  exaained  only: 

f  r oa_SNP • dtga.  f ragaent^of  f se t 
froa_SNP.  dtga.  ■ore_fra^f  lag 

b.  Return  values: 

NO  -  the  datagraa  has  not  been  fragaented 

YES  the  datagraa  is  a  part  of  a  larger  datagraa 

if  ( (froa^SNP. dtga. fragaant^of feet  •  0)  **contaios  the 

beginning 

and  (froa^SNP.  dtga.  aore^frag^f lag  *0))  —and  the  end 

of  the  data 

than  return  NO  —therefore  it  is  an  unfragaanted  datagraa 

else  return  YES;  — othenrise  it  contains  only  a  portion  of 
the  data 

—and  is  a  fragment. 

end  if; 

9.4.6. 2 .2  Can  frag?  The  esn^frag  function  caaaines  the  "don't  fragment" 
flag  of  the  interface  paraaeten  allowing  fragaentation.  The  data  effects 
of  this  function  are: 

a.  Data  mained  only: 

f  roa^ULP  •  dont^f  r  egaent 

b.  Return  values: 

NO  -  "don't  fragment"  flag  is  eat,  preventing  fragaeir- 
tetion 

YES  •  "don't  fragment"  flag  is  NOT  set,  to  allow  frag¬ 
ment  at  ion 

if  (froaJULP.dottt_fragaent  •  TtOE) 
then  return  NO  ~ 
elee  return  YES 
end  if; 
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9«4«6*2«3  Chscksua  vslld?  The  checksua^vslld  function  exaiilnes  sn  Incoelng 
dstsgrsa's  header  to  detemlne  whether  It  is  free  froa  transalssion  errors* 

The  date  effects  of  this  function  ere: 

e.  Date  examined  only: 

f  r  om^SNP  •  dtgm.  ve  rs  Ion 
from^J^  .dtgm.  heads  r_length 
f  rom^**^  •  ^tgm*  ty  pe^ofjse  rvlce 
from^SNP  .dtRa*  total^Iength 
f romJSNP , dtga. Identlf Icat Ion 
f  r  *  ^tgm«  dont_f  ragjf  lag 

fromJSNF.  dtgm.  aore_frag_f  lag 

offset 

f  rosijS**^  •  dtgm.  t  Ims^toJTl  ve 
f  r  om^SNP  •  dtgm.  protocol 
f  rom^S^*  dtgm.  source_sddr 
from^^  *dtgm.  destlnatlon^addr 
from_SNP  •  dtgm.  options 

b.  Return  values : 

NO  checksum  did  not  check.  Indicating  header  fields 
contain  errors 

TES  checksum  was  consistent 

•—The  checksum  algorithm  Is  the  16-hlt  one's  complement 
-*-of  the  one's  complement  sum  of  ill  Ib^'blt  words  In 
-»the  IP  header.  For  purposes  of  computing  the  checksum, 
—the  checksum  field  Is  set  to  sero. 

—Implementation  dependent  action 

9. A .6. 2 .4  Icmp  checksum?  The  Icmp^checksum  function  computes  the  check* 
sum  of  the  ICHP  control  measagi  carrl^  In  the  data  portion  of  the  Incoming 
datagram.  The  data  effects  of  this  procedure  are: 

a.  Data  examined: 

f  romJSNP .  dtgm.  data 

b.  Return  values: 

NO  —  checksum  did  not  check  Indicating  the  control 
messagB  contains  errots 
TES  —  checksum  war  consistent 

—The  checksum  algorithm  is  the  16*blt  one's  complement  of 
**the  one's  complement  sum  of  all  16*bit  words 
— In  ICMP  control  mcesage.  For  purposes  of  computing  the 
checksum. 
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— the  chtcksua  field  (octets  2-3)  is  set  to  zero. 

— Ispleaentstlon  dependent  set Ion 

9.4.6.2.5  Heed  to  frsg?  The  aead_to_frsg  function  exsnlnes  the  interface 
psrsaeters  end  date  fro*  s  ULP  to  dsTeralne  whether  the  data  can  be  transait- 
ted  as  a  single  datsgraa  or  aust  be  transaitted  as  two  or  more  datagraa 
fragaents.  The  data  effects  of  this  function  are: 

a.  Data  exaained  only: 

froaJJLP.  length 
f r oaJULP • op t ions 

b.  Sleturn  values: 

NO  -  one  datsgraa  is  saall  enough  for  the  subnetwork 
YES  -  datagraa  fragaents  are  needed  to  carry  the  data 

— Coapute  the  datsgraa's  length  based  on  the  length  of  data, 
—the  length  of  options,  and  the  standard  datagraa  header  sise. 

if  ((  fraaJDLP. length  -f  (nuaber  of  bytes  of  option  data) 

>  20)  >  aaxlaua  transaission  unit  of  the  local 
subnetwork) 
then  return  YES 
else  return  NO; 
end  if; 

9. 4 .6 .2 .6  Reass  done?  The  reass^done  function  exaaines  the  incooii^  datr* 
graa  and  the  reosseably  resources  to  deteraine  whether  the  final  fragaent 
has  arrived  to  coaplete  the  datagraa  being  reasseabltd.  The  data  effects  of 
this  function  are: 

s.  Data  exaained  only: 

state^vector.  reasseebly^aap 
state__vector.  tot  aljdata^length 
f  r  oa_?NP .  dtga.  tot  al^leiiith 
f  r  oa^SNP .  dt  ga.  aoreJF rag^f  lag 
froaJSNP.  dtga.heaf r^length 

b.  Return  values: 

NO  -  aore  fragaents  are  needed  to  coaplete  reasseably 
YES  -  this  is  the  only  fragaent  needed  to  coaplete 

reasseably 

—The  total  data  length  of  the  original  datagraa,  as  coaputed 
— froa  "tail"  fragaent,  aust  be  known  before  coapletlon  is 
—possible. 
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If  (state__vector. total__dats__length  •  0) 
then 

—Chech  incQBing  detagraa  for  ‘’tall." 

If  (fro«JSNP.dltgTi.aore__frag_f lag  -  FALSE) 
then 

-‘K^ooipute  total  data  length  and  see  if  data  In 
—this  fragflont  fill  out  reasseiobly  aap. 

if  (8tate__vector.reas8enbly_«ap  froa  0  to 

(((fro«SNP.dtga.total~ltngth  -  —  total  data 

(froirj5NP.dtga.headirr__lengthH)+7)/8) —  length 
't‘7)/8  is  set) 
then  return  YES; 
end  if; 


else 

— Reasseably  cannot  be  coeplete  if  total  data  length  unknown, 
return  NO; 
end  if; 

else  —Total  data  length  is  already  known.  See  if  data 
—in  this  fragesnt  fill  out  reasseiid>ly  nap. 

if  (  all  reasseably  aap  froa  0  to 

(state^vector. total_^data^length'*'7)/8  is  set) 
then  return  YES;  —  final  fragment 
else  return  NO;  —  aore  to  coae 
end  if; 
end  if; 

9.4. 6. 2. 7  SNP  paraas  valid?  The  SNP^araas^valld  function  exaalnes  the 
Interface  paraaeters  and  the  datagraa  received'^froa  the  local  subnetwork 
protocol  to  see  if  all  values  are  within  legal  ranges  and  no  errors  have 
occurred.  The  data  effects  of  this  function  are: 

a.  Data  ea^aained  only: 

froajSNP.dtga. version 
froa3^*^i8>-  heads  r^length 
f  r  oaJS» .  dtga.  cot  al^lengt  h 
fraa3^ 

otheT  inforaation/errors  froa  SNP 

b.  Return  values: 

NO  ~  some  value  or  values  are  illegal  or  an  error  has 
occurred 

YES  exaalned  values  are  within  legal  ranges  and  no 
errors  have  occurred 
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if  (  —Tbs  current  IP  header  version  nuaber  is  4* 

(frosi_SNP«dtga. version  /■  4) 

—The  ainiasl  IP  header  is  5  32-bit  units  in  length, 
or  (frosi_SNP.dtgB»hesder_length  <  5) 

—The  sasllast  legal  detsgrsa  contains  only  a  header  and  is 
—20  octets  in  length, 
or  (froa_SNP.dtgB.total_langth  <  20) 

—The  legal  protocol  identifiers  are 
—available  free  the  DoD  Executive  Agent  for  Protocole. 
or  (frosi  SUP. dtga. protocol  is  not  one  of  the  acceptable  identi- 
fianT 

) 

then  return  NO 

else  if  (any  iapleaentation  dependent  values  received  froa  the 
SNP  are  illegal  or  indicate  error  conditions) 
then  return  NO 

else  return  TS8;  -K>thexifiset  all  values  look  good, 
end  if; 
end  if; 

9. 4. 6. 2. 8  TTL  validt  The  TTt^valid  function  esaainoe  the  IP  header  tlat- 
to**live  field  of  an  ineoatng  datagraa  to  detendne  whether  the  datagraa  has 
exceeded  its  allowed  Ufetlne.  The  date  effects  of  this  finction  aret 

a.  Data  exaained  only: 

f  roaJINP  .dtgn.  tlae_to_live 

b.  Return  valu«ist 

NO  -  the  datsgrsa  has  expired 

YES  *  the  datagraa  has  seat  life  left  in  it 


— Decraaent  fraaJSNP.dtgaatlae^to^live  field  by  the  aexiaue 
—of  either  the  aaount  of  tiBs'%isSpsed  since  the  lest  IP  nodule 
—handled  this  datagraa  (if  known)  or  one  second. 

if  (  froaJIIV.dtga.tiBi_to_live 

-  aaxiaua  (nuaber"" of  ""seconds  elapsed  since  lest  IP,  1) 

<-  0  ) 

then  return  NO 
else  return  YES; 


so 
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9.4,6,2,9  OLP  par—  vlid?  Tha  ULP^raMi_valld  funetlou  axa^naa  tha 
Intarfaca  paraaataia  racalvad  froa  a  UIP  to  aaa  if  all  yaluaa  ara  wlthiu 
lagal  rangaa  ai^  daairad  optlona  ara  aupportad*  Tha  data  affaeta  of  thla 
funetlou  ara: 


a.  Data  axaalnad  only: 

f  roaJJLP  •  t  l«a_to_Uua 
f r oaTULP • op t Iona 


b«  Ratum  valuaa : 

NO  *■  aoaa  valua  la  lllagal  or  a  daairad  option  la  not 
support ad« 

TRS  -  axaolnad  valuaa  ara  within  lagal  rangaa  and  daairad 
optlona  can  ba  support ad* 

If  < 

—Tha  tlaa-to-llva  valua  must  ba  graatar  than  taro  to 
—allow  IP  to  tranaalt  It  at  laaat  onca* 

(froaJILP.tlBa_to_Uaa  <  0) 

or  —Tha  options  raquastad  ara  Ineonalatant* 

'^iwplaaantatlott  dipandant  action 

or  — Othar  laplaaontatlon  dapandant  valuaa  ara  Invalid* 

— laplaaantatlon  dapandant  action) 

chan  ratum  NO 

alaa  raturn  YES; 

and  If; 

9.4.6.2*10  Vhara  ^atT  Tha  wharajdast  function  datamlnaa  tha  dastlna- 
rlon  of  an  outgoing  dlatagraa  by  a?iaadnlng  tha  daatlnatlon  addraaa  auppliad 
by  thd  UUP.  Tha  data  at  facta  of  thla  function  ara: 

a*  Data  axanlnad  only: 

f  r  onJJLP .  da  a  1 1  nat  leo_addr 

b*  Raturn  valuaa: 

ULP  -  daatioatloa  la  an  uppar  Liyar  protocol  at  this 
location 

RA40TE  -  dtatlnatlon  la  ao«o  r«B»ta  location 

— Bxanlna  tha  <^t^uatlon  addraaa  flald  of  the  datagram 
harder* 
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If  (froi_8IIP.4tgm«dsstiastlonjiddr  /*  this  sltt's  sddrsss) 
thsn  rsttn  RBMOTB  ^ 

slss  rstum  ULF; 
sod  if; 

9.4.6.2.11  Whsrt  toT  Ths  vhsrsjte  fuaetioa  dstsmioss  ths  dsstinstion 
ths  incoBiog  ^tsgrsB  by  sxsaiarng  tbs  sddrsss  fislds  sad  opticas  fields 
tbs  dstsfrsB  bssdsr.  Tbs  dsts  sf  fsets  of  this  fuaetioa  srss 

s.  Dsts  sasaiasd  oaly: 

f  rosjniF  •  dtgB.  dis  tiastioBjiddr 
f  roBjl*  •  dtga*  protocol 
f  roiJIlIP  •  dtfB.  op  t  ioas 

b*  tstura  Tsluss  x 

Ulf  *  dsstiastioa  is  sa  upper  Isysr  protocol  st  this 
loestioB 

ICKF  dsstiastioa  is  this  I?  aoduls  bsesuss  tbs 
dstsgrss  carries  sa  IQfF  eoatrol  assssts 
IMon  -  dsstiastioa  is  sobs  rsaots  loestioa 


-*Tbs  source  routs  iaflusaess  tbs  dstsgrsB's  fstsvsy  routs. 

if  ( (froBjW  •  dtfB.  opt loas  eoatsias  tbs  source  routiag 
optloe)  sad  (ell  source  routs  list  sddrsssss  bsut 
act  beta  risitsd)) 
thsa  rstum  AMTI; 
sad  if; 

— CxsBias  tbs  dsstiastioa  adless  field  of  tbs  dstsfres 
bssdsr. 

if  (fras_SllP.dtgB.distiastioBji4dr  /•  this  sits's  sddrsss) 

tbsB  ~  “ 

-'-It's  dsstiasd  for  ssotbsr  sits, 
return  MMOTI 

sloe 

**lt*s  dsstiaad  for  this  sits, 
if  (froajitf*  dtfB. protocol  •  tbs  ICMf  protocol  idsati* 
fisr) 

tbsB  retura  lOIF 
slss  return  DLF; 
if; 

sad  if; 


9.4 .8. 3  Dscisioe  table  setioe  proesdsrus.  Tbs  folloviag  set lea  preesdurss 
rsprsssat  t^M  set  set  ioas  sa  9  stats  aschias  sbould  psrfora  ia  rospoass  to 
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s  psrtlculsr  svuat  and  iatsnial  atatif*  Thaaa  procaduraa  ha^  baaa  orgaalaad 
aid  daaifaad  for  clarity  aad  art  lataadad  aa  fuidaliaaa.  Although  Ittpla* 
motors  say  la  fact  raorgaolM  for  battar  parformaea»  tha  data  affacta 
of  Om  raoultli^  laplaMOtatlooa  aust  aot  dlffar  froa  thoaa  apaelflad  balov. 

9.4.6.3.1  Analyaa,  Tha  aoalysa  procadura  axaaloaa  datagram  cootalaiog 
ICKP  eoatroX  aasaagaa  froa  otbar  X?  aodulaa*  In  gaoaraI»  arror  haadliog  la 
l^laaiotatloo  dapaodaot.  Howaaar,  guldallaaa  ara  provldad  to  Idaotlfy 
elaaaaa  of  arrors  and  augpat  upproprlata  actloaso  Tba  data  affacta  of  this 
procadura  arat 

a.  Data  axaalnadi 

f  roajniF  •  dtga.  protocol 
f roa^SNP • dtga. data 

b.  Data  aodlflad: 

iaplanaatatloa  dipaiidaat 

for  sl^ilclty.  It  la  aaauaad  that  tba  data  araa  can  ba  accaaaad  aa  a  byta 
array. 

— Isaalaa  tht  flrat  octat  la  tha  data  portion  to  Idaotlfy  tha 
*^rror  typa  aad  subsaquant  foraat. 

bagln 

cma  froaJIMf.dtgBd)  of 

vhan  3  •>  *-Otatltatlon  Daraachabit  Maasaga 

—Tba  arrora  la  the  *mraadiabla*  class 
— atettld  ha  pasaad  to  tha  ULF  Indicating  data  daUvary 
—to  tha  dastlnatloa  la  uallkaly  if  aot  lapoaalbla. 

— Thi  aacoad  octat  Idaatlflaa  what  lawal  was  unraachabla. 

case  fr<ai_SliP.dtgn(2l  of 

whan  0  •>  — aat  uaraaehabla 

whan  i  »>  —host  mraachabla 

whao  2  »>  —protocol  uoraacHabla 

whaa  3  «>  —port  uaraaehabla 

whan  4  •>  — fragaantatloa  aaadad  and  don't  fragnaat  aat 
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vhun  5  •>  — sourcs  routs  fallsd 

•od  cast; 

whoa  11  ■>  — TIm  Exeosdod  Motsagt 

— Tbo  ”tlat*out*  orron  art  usually  not  passtd 
—to  tbs  tn^  but  should  fas  rscordsd  for  astvork 
— aoaitorlng  usss* 

cass  froBjIVP.dtga  of 

vbsa  0  ->  — ^Ijsi  to  Uvs  sscssdsd  la  transit 
whan  1  ->  — Fragasnt  rsasssibly  tlas  sxessdsd 
sad  cass; 

when  12  •>  — Paraastsr  Profalsa  Hsssags 

—This  srror  is  paaratsd  fay  a  fitcway  IP  to  indicate 
—a  ^ofalaa  in  the  optioae  field  a  dsti^rsa  hsadst. 
—Octet  5  contains  a  pointer  uhich  identifies 
—the  octet  of  the  original  header  containing  the  error. 

uhcn  4  •>  —Source  Quench  Messap 

—This  nessage  indicates  that  a  dati^ren  has  been 

—discarded  for  congestion  control.  The  ULP  should 
—he  infomed  so  that  traffic  can  W  roducod. 

idien  5  ■>  — tedirect  Kessap 

—This  nessage  should  result  in  a  routing  table  updete 
—fay  the  IP  nodule.  Octets  5-8  contain  the  nmt  value 
—for  the  routing  tafalt.  It  is  not  passed  to  the  IJIP. 

uhen  8  •>  —Echo  Detagran 

uhen  0  *•>  —Echo  fteply  Detegrea 

when  13  •>  — Tinoetenp  Detagran 

lAen  14  •>  — Tines tenp  Eeply  Detigran 

idien  15  •>  — Infometion  toques  t  Message 

uhen  14  •>  -Infometion  teply  Nessage 

end  case; 
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--Call  the  route  procedure  to  determine  a  local  destination 
— from  the  Internet  destination  address  supplied  by  the  ULP. 

route; 

— Request  tie  execution  envlroment  to  pass  the  contents  of  tojSNP 
—to  the  local  subnetwork  protocol  for  transmission. 

TRANSFER  to_SNP  to  the  SNP. 

NOTE:  The  format  of  the  froin__L/U»  elements  is  unspecified*  allowing  an  imple¬ 
mentor  to  assign  data  types  for  the  interface  parameters.  If  those 
data  types  differ  from  the  IP  header  types*  the  a8>'lgnment  statements 
above  become  type  conversions. 


9. 4. 6. 3. 3  Compute  checksum.  The  compute^checksum  procedure  calculates 
a  checksum  value  for  a  datagram  header  so  that  transmission  errors  can  be 
detected  by  a  destination  IP.  The  data  effects  of  this  procedure  are: 

a.  Data  examined: 

to^SNP « dt gm. ve  rs ion 
toJS^*  <^f8a.header_length 
to^SNP  .dtgrn.  type^oT_8ervlce 
to_SNP. dtgm. totaT^length 
toJSNP .dtgm. identification 
tojSNP.  dtgm.  dont_frag_f  lag 
to_SNP .  dtgm.  aore_frag__f  lag 
tojSNP .  dtgm.  f  r  agment^of  f  set 
to_SNP .  dtgm.  t  lme__to_li  ve 
tojSNP .  dtgm.  protocol 
to_SNP .  dtgm.  sour  cejaddr 
tojSNP.  dtgm.  destination^addr 
tojSNP  •  dt  gm.  op  t  ions 

b.  Data  modified: 

tojSNP .  dtgm.  header_^checksum 

—The  checksum  algorithm  is  the  16-bit  one's  comt^ lament  of 
—the  one's  complement  sum  of  all  I6‘bit  words 
— in  the  IP  header.  For  purposes  of  computing  the  checksum* 
— the  checksum  field  is  set  to  zero. 

—implementation  dependent  action 

9.4. 6. 3. 4  Compute  iciiy  checksum.  The  coapute^icmp^checksum  procedure 
computes  the  checksum  of  the  ICMP  control  message  carried  in  the  data 
portion  of  an  outgoing  datagram.  The  data  effects  of  this  procedure  are: 
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9.4«6*3*2  Bulld&send*  The  bulld&send  procedure  builds  an  outbound 
datagram  in  the  toJSNF  structure  from  the  interface  parameters  and  data  in 
fromJJLP  and  passes  it  to  the  SNP  for  transmission  across  the  subnet.  The 
data  effects  of  this  procedure  are: 

a.  Data  examined: 

f  romJDIiP  .sourcejaddr 
fromJJLP.  destination^addr 
f r omJJLP . p r ot o col 
fromJJLP .  ty  pe^of jse  r  /ice 
fromJJLP .  identifier 

b.  Data  modified: 

toJSNP .  dt  gm  to^SNP .  type_ofjiervlce_indica  tors 

toJSNP. length  to  SKP. local  destination  addr 


fromJJLP  •  tlme_to_llve 
f  r  omJJLP .  dont_f  ragment 
fromJJLP • op  t ions 
fromlJLP. length 
fromlJIJP.data 


—Fill  in  each  IP  header  field  with  information  from  fromJJLP  or 
standard  values. 

toJSNP.  dtgm.  vers  ion:  •  4;  -Currant  IP  version  is  4. 

toJSNP.  dtgm.type^of^service.  indicators:  •  fromJJLP.  type__o£_^service; 

toJSNP.dtgm. Identification:  •  fromJJLP. identifier;  —If  ID  is  not  given 

—by  ULP,  the  IP  must 
— supply  its  own. 

toJSNP.  dtgm.dont_frag_f  lag:  •  fromJJLP.dont^fragment; 

toJSNP. dtgm. no rejfragjf lag:  -  fals7; 

toJSNP. dtgm.fragwnt^off set:  «  false; 

toJSNP.dtgm. tlae_to_^Uve:  -  fromJJLP.tlme_to__llve; 

toJSNP. dtgn. protocol:  -  ft omJJLP. protocol; 

to__SNP  .dtgm.  source^addr :  •  fromJJLP  .source^addr; 

toJSNP. dtgn. destination^addr:  -  fromJJLP. destination_^addr; 

toJSNP.dtgm.  options :  -  fromJJLP.  opt  ions;  ~ 

to_SN?.dtgn.header_length:  ■  5  +  (lumber  of  bytes  of  option  data)/4; 

toJSNP.dtgm.  total^langth:  -  ( toJSNP.  dtgm.  he  Oder  length)*4 

+  TfromJJLP. length) ; 

—Call  compute^checksum  to  coaq>ute  and  set  the  checksum, 
c  omput  e^che  cks  urn; 

-*^nd,  fill  in  the  data  portion  of  the  datagram. 

toJSNP. dtgm. data (0..fr on  ULF. length  -1  ]:  -  fromJJLP. data[0.. 

fronJJLP.length-ll; 

—Set  the  type  of  service  and  length  fields  for  the  SNP.  ~ 

toJSNP.  type_o£_servlce_lnd  lea  tors:  •  toJSNP.dtgm.  type_of_servlce; 
tOjSNP. length:  -  to_SNP. dtgm. tot al^length;  "** 
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a.  Data  examined: 


to^SNP • dtgm. data 


b.  Data  modified: 


to_SNP  •  dtgm.  data(  2-3  ] 

—The  checksum  algorithm  Is  the  16-blt  one's  complement  of 
—the  one's  complement  sum  of  all  16-blt  words 
— in  ICMP  control  message.  For  purposes  of  computing  the 
checksum, 

—the  checksum  field  (octets  2-3)  Is  set  to  zero. 
—Implementation  dependent  action 

9. 4. 6 .3. 5  Error  to  source.  The  errorjtojiource  procedure  formats  and 
returns  an  error  report  to  the  source  of  an  erroneous  or  expired  datagram. 
The  data  effects  of  this  procedure  are: 

a.  Parameters: 

errorj)aram  :  (PARAM_PROBLEM,  EXPIRED  TTL, 

PROTOGOLJJNREACH);  “ 

b.  Data  examined: 

fromjSNP.dtgm 


c.  Data  modified: 

toJSNP.dtga 
toJSNP. length 


to^SNP . local_des  t lnatlon_addr 
to_SNF.  type_of_scrvlce_lnd  lea  tors 


—Format  and  transmit  an  error  datagram  to  the  source  IP. 


tojS  NP  •  d  t  gm.  ve  rs  Ion 
to^SNP .  dt  gm«  he  ade  r_le  ng  t  h 
tojSNP .  dtgm.  typ«_of__se  rvlce 
toJSNP.dtga. Identification 
tojSNP  •  dtga.  Bor«_frag_f  lag 
tojSNP .  dtga.  dont_f  rag_f  lag 
toJSNP.dtga. fragmentjOffset 
tojSNP .  dtga.  t  lae_tOjll  ve 

tOjSNP.  dtga.  protocol 

tojSNP. dtga. source^  addr  : 

tOjSNP .  dtga.  des  t  Inat  lonjaddr : 


■  4;  —standard  IP  version 

*  5;  —standard  header  size 

»  0;  — routine  service  quality 

■  select  new  value; 

-  FALSE; 

-  FALSE; 

-  0; 

-  60;  —or  value  large  enough  to 
—allow  delivery 

^  this  number  will  be  assigned  by 
DcD  Executive  Agent  for  Protocols; 

*  froajSNP. dtga. des t inat ioOjaddr; 

*  froBiJSNP.dtga.source_addr; 
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—The  data  section  carries  the  ICMP  control  Message. 

—The  first  octet  identifies  the  message  type,  the  remaining 
— octets  carry  related  information. 


case  error__param  of 

where  PARAM_PROBLEM  -> 
to_SNP.dtgm.data[0] : 
to_SNP .  dtgm.  datai  1 J : 
to_SNP .  dt  gm.  da  ta[4  j : 

where  EXPIREDJTTL  -> 
to^SNP .  dt  gm.  da  t  a  [  0  ] : 
to^I^  •  dtgm.  datai  1  ] : 

where  PROTOCOLJJNREACB 
t  o_SNP .  dt  gm.  da  t  a  [  0  ] : 
to_SNP .  dtgm.  datai  1  ] : 

end  case; 

—The  bad  datagram's  header 
—data  section  (a  total  of 
— the  ICMP  infomation. 


-12;  — ICMP  type  -  Parameter  Problem 

-  0;  —Code  -  problem  with  option 

-  position  of  error  octet; 


-  11;  —ICMP  type  -  Time  Exceeded 

■  0;  —Code  -  TTL  exceed  in  transit 

-> 

-  3;  —ICMP  type  -  Dest.  Unreachable 

-  2;  —Code  -  protocol  unreachable 


plus  the  first  64  bytes  of  its 
*7}**  octets)  Is  copied  in  following 


to_SNP.,dtgm.datal8..N+3j:  -  froeiJ5NP.dcgm.data[0.  .N-1  ] ; 
to^SNP. dtgm. tot al^length:  -  fi:ca_j;N'r'.hea«!ar__length*4  +  N  +  8; 
comput  e^icmp^checksum; 


--Compute  checksum,  detemlne  the  route  for  the  error  datagram, 

—the  type  of  service  indicators,  and  the  datagram  size  for  the  SMP. 


comput  e^checJwum; 

to__SNP.type_of jservlce^lndlcators:  -  0; 
to_SNP. length  to_SW. dtgm. tot al__length; 

route; 


—Request  the  execution  environment  to  pass  the  contents  cf  to^SMP 
—to  the  local  subnet  protocol  for  transmission.  ^ 

TRANSFER  toJSIJP  to  the  SNP. 

9. 4. 6 .3. 6  Error  to  ULP.  The  errorjto^ULP  procedure  returns  an  error  report 
to  a  ULP  trhich  has  passed  invalid  parameters  or  has  requested  a  service  that 
cannot  be  provided.  The  data  effects  of  this  procedure  are: 

a.  Parameters: 


errotj>aram;  (PARAM_PROBLRM,  CAN'T  FRAGMENT, 
NETJINREACH,  PROTOCOL JINREACH , 
PORT  UNREAOl); 
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b.  Data  exanlaed: 

iiipleisentatioa  dependant 

c.  Data  uodifled: 

toJJI^^nrror 

inplanentatlon  dependant  paraueten 

—The  foraat  o£  error  reports  to  a  DLP  is  inplenentation 
—dependent*  However,  Included  In  the  report  should  be 
—a  value  Indicating  the  type  of  error,  and  sowe  Inforwatlon 
—to  Identify  the  associated  data  or  datagraa* 

toJJLP. error  error^paran; 

**-lBpleaMntatlon  dependent  action 


9. 4. 6. 3. 7  PraSBentisend*  The  fragBent&send  procedure  breaks  data  that  Is 
too  big  to  be  transBltted  through  the  subnetwork  as  a  single  datagraa  Into 
saaller  pieces  for  transalsslon  In  sevsral  datagraas*  Noraally,  hosts  do 
not  seal  datagraas  too  Ug  to  go  through  their  own  network.  The  data  effects 

of  the  procedure  are: 

a*  Data  exaalned  only: 


f  roaJUIf  •  sour  cejsddr 
froaJJLP*  destlnatlon^^addr 
froa*DlJP  .protocol 
froajn.P.  Identifier 
f  r  qb^IjuP  .  dont_f  ragaent 


froaJVLP . length 
froa^JlUP  •  data 
froa”ULP.  options 
froa‘~ULP.tlae  to  live 


b.  Data  aodlfled: 


to_SNP  •  dtga  to_SNP .  typejof_8ervlce_lndlca  tors 

to  SNP. length 


c.  Local  variables: 

nu^er_of_fragaBnts  —  nuaber  of  saall  datagraas  created 

froa  user  data 

dataj)er_frag«nt  —  the  nuaber  of  octets  In  each  saall 

datagraa 

nu^er  frag^blocks  —  the  nuaber  of  8-cctet  blocks  In  each 
^  saall  datagraa 

data  ln__laat__frag  —  the  nuaber  of  octets  In  the  last 

datagraa 

j  —  loop  counter  for  each  fragaant  generated 
— Coapute  the  fragaentatlon  variables. 

—The  saount  of  data  per  fragaant  equals  the  aax  datagraa  sl*e 

less 
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-*^he  length  of  the  dategraa  header. 

data_per_^fragiaent:  -  naxiiiuii  subnet  transaisslon  unit 
-  (20  nuaber  of  bytes  of  option  data); 

nunber^fra^blocks:  -  datajper_fragiient/8; 

nui!d>er_of jfragasnts:  -  (froaJOLP.  length  +  (dataj>er_frag- 
~  oent-D)  /  data_per_fragaentT 

data_ln_^  lastjfrag:  -  froaJJLP.  length  aodulo  dataj>er^frag- 
“  aent;  *“ 

—Create  the  first  fragaent  and  transalt  It  to  the  Sl^fP• 

to^SNP.dtga. version:  -  4; 

to_SNP.dtga.headerJLength:  -  5  (nuaber  bytes  of  option 

“  data  A); 

to^SNP  •  dtga.  tot  al^length:  ■  to^SNP  •  dtga.  header^lengt  h 

't'  data_per_fragaent; 

tojSKP.  dtga.  identification:  ■  froBjJLPTidentifier; 
to^SNP. dtga. dont_frag;_f lag:  «  froaJDLP.dofit^frafasnt; 

~  — thTs  will  be  false 

toj»NP.  dtga.  aore^frag^^f  lag:  ■  TRUE; 
to_SNP.dtga.fra^ntjoffset:  -  0; 

toJSNP.dtga.tiae^to^live:  •  froaJ5LP.tlae_^to^live; 
to_SNP.dtga.prot7e<^:  •  froaJUlPTprotocolT  ~ 
to_SHP.  dtga.  sour  ee^eddr:  ■  fToaJJLP .  souree^eddr; 
toJ5^«dtga«destinatton_addr:  froaJJLP.f stination^addr; 

to^NP*  dtga.  options:  froa^DLP.  options: 

toJ5NP.dtga.data(0.  .data_per~ fragaent*!]:  ■ 

TroaJJiP.  d  :ta[0.  •  data^^r^ 
ffagwnt*!]; 

—Set  the  dategraa 's  header  checkaua  field, 
coaput  ejchecksus: 

*-<all  route  to  detetaine  the  subnetwork  address  of  the 
—destination, 
route; 

—Also  set  the  length  and  type  of  service  indicators. 
toJSNP.  length  t-  toJSHP.dtga. total_lengtb; 
to_SNP . ty pejof jic tvTcejlndlcators  : •  to^SNP . dtga. type_ 
ofjiervice;  ”  ~ 

**Requast  the  execution  environaent  to  pass  the  first  fragaent 
— to  the  SNP. 

TRANSFER  to^SNP  to  the  local  subrietwock  protocol. 

—Format  and  transmit  successive  friigaents. 
for  J  in  1« .taiaberjof^fragaents*!  loop 
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—The  header  fields  reaain  the  same  as  in  the  first 
—fragment,  EXCEPT  for: 

if  ("copy"  flag  present  in  any  options)  —most  signi- 

—f leant  hit 
—of  option 
—octet 

then  —put  ONLY  "copy"  options  into  options  fields  and 
—adjust  length  fields  accordingly* 

toJSNP.dtgsu  opt  ions:  ■  (options  with  "copy"  flag); 
toJS^«<ltgm«header^length:  ■  S  't' 

""  (number  of  copy  options 

octets /4); 

else  —only  standard  datagram  header  present 
to_SNP«dtgm.header^length:  ■  S; 
end  if; 

—Append  data  and  set  fragmentation  fields, 
if  (J  /-  number_^of^fragments-l ) 

then  —middle  fraimsnt(s) 

toi^SMP  •  dtgm.  more^f  r  a|_f  lag :  •  TRUE ; 

to3^«^tgm.fragment_of fset:  ■  j*nuaber  frag^blocks; 
to3l^*^tgm.total_length:  -  toJ5NP.4tgm7Keader_length 
”  +  data_per_fragment; 

to_SKP.dtgm.data(0..data^j>er_fragment'-l  ]:  ■ 

“  fromJJLP.data[J*data^er_Jrag- 

mantT.  (j*data^_per_fragsient 
dsta^per^fragment**!)] ; 


else  —last  fragment 

to_SNP.dtgm.more_frag_fIag:  -  FALSE; 
toJiKP.  dtgm.  fragsmnt^off  set:  ■  j*nunber_frag^blocks; 
to^NP. dtgm. tot al_le^th:  -  toJSNP.dtga.header_length*4 
""  ""  +  data_in_last_frag; 

to_SNP.dtgm.  data[0.  .data^^ln^last^fraf-l ) :  ■ 

from  ULP[ J*data^er^frafment. . 
(j'^data^per  fragment^  data_ln_ 
iast_frag-l7l ;  ” 

end  if; 

—Call  checksum  to  set  the  datagram's  header  checksum  field, 
checksum; 


61 


i  ^ 


M35 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


MIL-STD-1777 
12  August  1983 


*-*<:all  route  to  detemlne  the  subnetiroik  address  of  the 
destlQstloQ. 
route; 

'—Also  set  the  length  and  type  of  service  indicators* 
toJSKP.  length  to_SNP*dtgm*total_length; 
to”SNP  •  ty pe_of_^se rvlce_J.ndlca to rs  T«  to_SNP  •  dtgm*  ty pB_^of_^ 
service; 

--Request  the  execution  envlronneiit  to  pass  this  fragnent 
—to  the  SNP. 

TRANSFER  to_SNP  to  the  local  subnetwork  protocol* 
end  loop; 

A  fragmentation  algorithm  nay  vaiy  according  to  Implementation  concams  but 
every  algorithm  must  meet  the  following  requlremants: 

a*  A  datagram  must  not  be  fragmented  If  dtgm*dont_frag_flag  Is  true* 

b*  The  amount  of  data  In  eadi  fragment  (except  the  last)  must  be  broken 
on  8-octet  boundaries* 

c.  The  first  fragment  must  contain  all  options  carried  by  the  original 
datagram,  except  padding  and  no-op  octets* 

d*  The  security,  source  routing,  and  streem  identification  options 

(l.e*  marked  with  "copy*  flag,  MSB  In  option  octet)  must  bn  carried 
by  all  fragments.  If  present  In  the  original  datagram* 

e*  The  first  fragment  must  hamt  toJ5NP*dtgm*fragmsnt_offset  set  to 
sero* 

f*  All  fragments,  except  the  last,  must  have  to^SN?*dtgm*morejfrag_flag 
set  true. 

g.  The  last  fragment  must  have  the  toJ5NP*dtgm*more^frag^flag  set 

false* 

9. 4. 6*3*8  Local  delivery*  The  local^dellvery  procedure  movos  the  Interface 
parameters  and  data  In  the  fromJJLP  structure  to  the  to^ULP  structure  and 
dellvere  It  to  an  lir-host  ULP*  ~the  data  effects  of  this  procedure  are: 

a.  Data  examined: 

fromJlILF.destlnatlonjiddr  fromJfflP.  length 

f  r  om3JLP  •  aource^addr**  f  romJJLP .  data 

froaJILP. protocol  fromJJLP* opt lone 

fron~ULP* type  of  service 
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b.  Dsts  Bodified: 

to^piP  • sour ce^sddr  toJJLP • length 

toJJLP  •  des  t  IniTt  loo^addr  toJJLP  .date 

to3n-P* protocol  "*  toJJLP  •opt ions 

toJJLP  .type  of^servlce 


—Hove  the  Interface  paraaeters  and  data  from  the  Input 
-—structure*  fromJJI^*  directly  to  the  output  structure, 
—toJJLP,  for  delivery  to  a  local  UIP. 

fromJJLP.destlnatlon^addr:  ■  toJJLP.  des  tlnatlon^addr; 
fromJJLP.source^addr  :  •  toJJLP.  sour  ce_ad  dr; 

fromJJLP*  protocol  :  -  toJJIP. protocol; 

fromJJIP.typejofjiervlce  :  -  toJJLP. type_j)f_iervlce; 

fromJJLP. length  :  -  toJJLP.  length; 

fromJJlP.data  >  toJJLP.data; 

fromJJLP.  opt  Iona  :  ■  tcJJLP.  options; 

—Request  the  execution  envlronmant  to  pass  the  contents  of 
— toJSNP  to  the  local  subnet  protocol  for  transmission. 

TRANSFER  toJJLP  to  toJJLP .proto col. 

9.4.6.3.9  Reassembly.  The  reassciibly  procedure  reconstructs  an  original 
dat^ram  from  datagram  fragments.  The  data  effects  of  this  procedure  are: 

a.  Data  examined: 

from^SNP.dtgm 

b.  Data  modified: 

s  tate^vector  •  reassemblyjaap 
atate^vector.tlmer 
s  t  starve  cto  r  •  tot  al_da  t  a^le  ngt  h 
state^vector.headeT  ^ 
s  t  a  t  ct  o  r .  da  t  a 

e.  Local  variables: 

J  —  loop  counter 

data^ln^frag  —  the  number  of  octets  of  data  In  received 
fragmsnr 
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data_in_frag:  •  (froB_^SNP.dtg«.tot4l_langth-frai_^51IP. 
dtgii.  header^le  iigth*4  ) ; 

—Put  data  in  ita  ralativa  position  in  the  data  area  of  the 
state  vector. 

atate_vector.data(£r<M_SNP.dtgm.£ragBent_of£set*8. . 

£r  oeJSNP .  dtge.  fr^geent_o££aat*8+data^in_£rag  J :  • 

£roB_SNP.dtg«.data[0. .data^injErag-l ] ; 

— Pill  in  the  corresponding  entries  of  the  reassei^ly  nap 
—representing  each  8-octet  unit  of  received  data. 

for  j  in  (frosiJ5NP.dtgs.frag«nt_offaet).. 

((frGliJ5I{P.dtga.frageen^of  fset  +  data_jln_^frag  + 
7)/8)  loop 

otate_vector.reasseabl7_aap[  j]:  1; 

end  loop; 

— Coipute  the  total  datagraa  length  froa  the  "tail-end” 

— fr^gnent. 

if  (froB^SNP.dtge.aore_frag;_flag  ■  FALSE) 
then  staTe_vector.total^data^length:  • 

“  ?raa^NP.dtgm.frageentjoffset*8  + 

data^n.^reg; 

end  if; 

— Eecord  the  heeder  of  the  "head-end"  fragaent. 

if  (froaJSNP.dtga.  fragaent^offset  *  0) 
then  state^esctor. header  :•  froa_SHP.dtga; 
end  if; 

-Hteset  the  reasseably  tiaer  if  its  current  value  is  less 
—than  the  tiae-to-live  field  of  the  received  datagraa. 

state^vector. tiaer:  •  aaxiaua 

^  (froa_SNP.dtga.tiae_to_Uve,  state_vector. tiaer); 

A  reasseablj  algoritha  aay  vary  according  to  iapleeentation  concerns,  but 
each  one  aust  acet  these  requiraet'nts: 

a.  Every  destination  IP  w>dutc  aust  have  Che  capacity  to  receive  a 
datagraa  S76  octets  in  length,  either  in  one  piece  or  in  fragasnts 
to  be  reasseabled. 
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b*  The  header  of  the  fragment  with  froajSNP.dtga* fragiaenc__offset  equal 
to  zero  (l.e*  the  ‘*head'*end'*  fragnent)  becoaes  the  header  of  the 
reassembling  datagram* 

c*  The  total  length  of  tlie  reassembling  datagram  is  calculated  from  the 
fragment  with  froajSNP.dtga. ioorG_freg__flag  equal  to  zero  (i.e* »  the 
’’tail-end’*  fragment)* 

d.  A  reassembly  timer  is  associated  with  each  datagram  being  reassem¬ 
bled.  The  current  recommendation  for  the  initial  timer  setting 
is  IS  secouds.  Note  that  the  choice  of  this  parameter  value  is 
related  to  the  buffer  capacity  available  and  the  data  rate  of  the 
transmission  medium.  That  Is,  data  rate  multiplied  by  timer  value 
equals  reassembly  capacity  (e.g.iOKb/s  X  ISsecs  **  ISOKb). 

a*  As  each  fragment  arrives,  the  reassembly  timer  is  reset  to  the  maxi¬ 
mum  of  state^vector.reassembly^resources* timer  and  from^SNP.dtgm* time 
to^live  in  the  incoming  fragment* 

f*  The  first  fragment  of  the  datagram  being  reassembled  must  contain 
all  options,  except  padding  and  no^op  octets* 

g*  The  source^addr,  destination^addr ,  protocol,  end  identifier  of  the 
first  fragment  received  must  be  recorded*  All  subsequent  fragments* 
source^addr,  destination^addr ,  protocol,  and  identifier  will  be 
compared  against  those  recorded*  Those  fragosents  which  do  not 
match  will  be  discarded* 

h*  As  each  fragment  arrives,  the  security  and  precedence  fields,  if 
available,  must  be  checked*  If  the  security  level  of  the  fragment 
does  not  match  the  security  level  of  the  datagrem  or  if  the  prece¬ 
dence  level  of  the  fragment  does  not  match  the  precedence  level 
of  the  datagram,  the  datagram  being  assembled  is  discarded*  Also, 
an  error  datagram  is  returned  to  the  source  IP  to  report  the 
’’mismatched  security /precedence”  error. 

1*  If  the  reassembly  timer  expires,  the  datagram  being  reassembled  is 
discarded*  Also,  an  error  datagram  la  returned  to  the  source  IP  to 
report  the  "time  exceeded  durii^  reassembly”  error. 

9*4*6*3*10  Reassembled  delivery.  The  reassembled^de livery  procedure 
decomposes  the  diet agr am  that  has  been  reassembled  In  the  state  vector  Into 
interface  parameten  and  data,  then  delivers  them  to  a  UhP.  The  data  effects 
of  this  procedure  are: 

a*  Data  examined: 

•  t  a  t  e^ve  c  t  o  r .  he  ad  e  r  *  de  a  1 1  na  t  lo  n_ad  d  r 

■  t  a  t  e_ve  c  to  r .  heade  r  *  sour  ce^^addr 

•  tate^^vcctor.headcr.protocol 

■  tatc__vector.header. type  of  service 
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8tste_VBetor*hssdsr*hssdsr  Isngth 
•tsts^vsctor  •  hssdsr  •  tot  sl^Tsngth 
8  tst  e_vs  et  or  •bssds  r  •  opt  Ions 
ststt^vector  •  dots 

b*  Dots  uodlflud: 

toJJLP.iostiiistloiijiddr  toJDLP.Isogth 

tojnJP.oourcs^sddr  to^OlP^dsta 

toJILP .protocol  toJJLP • options 

to3^*typt  o£^S8rvlc8 


t  o^LP  •  ds  8 1  Inst  ionjiddr : 

toJJLP.sourcsjiddr  : 
toJJLP. protocol  : 

toJ3LP.typ8jo£^8«rvlc«  : 

to  ULP. Isngth  : 


toJULP. options 
toTuiP.dsts  : 


•  8tstt_8sctor.hssdsr.ds8tins_ 
tion^sddr; 

■  ststs^'fsctor.hssdsr.sourcsjiddr; 
-  ststs^Nictor.hssdsr.protocol; 

•  ststs_8sctor.hssdsr.typtjof_ 

ssnrios;  * 

•  ststs^snctor.hssdsr.tctsl^ 
Isngth; 

•  ststs  ssctor.hsadsr.hssdsr^ 
lsngtK*4; 

*•  ststs^ssctor.hssdsr.  options; 

•  8tstt*"8sctor.dsts; 


9.4.6.3.11  Issssssbly  tissout.  Ths  rossssibly  tiasout  procsdurs  gtnsrstss 
sn  srror  dstsgrsa  to  tins  soures  XP  informing  it  of  ths  dstsgrsa's  sxpirstion 
durii^  rsssssablj.  Ths  dsts  sffscts  of  ths  procsdurs  srs: 


s.  Dsts  sssminsds 


8 tst  s^ss ct o r • hssds r 
ststs^vsctor.  dsts 

b.  Dsts  sodifisd: 


toJSNP  .dtgs  to^SIIP  •  typsjof jisrvics^indicstors 

tojSNP  •  Isngth  to^SIV  •  hssdsr^lsngth 

-^onsst  sod  trsosnlt  sn  srror  dstsgram  to  ths  soures  IP. 


tojS  HP .  dtga.  vs  rs  ion 
CO JSKP .  dt  gs.  hssds  r_ls  ng  t  h 
cojSNP.  dtgtt.  typs^of^ssrrics 


•  4;  *-^tsodsrd  IP  version 

•  3;  -^tsadsrd  hssdsr  slss 

•  0;  — routins  ssrvics  quality 


to  JSKP • dtgs.  Identifies t ion 
te_S» .  dtga.  ssrc_f  rsjjf  leg 
to  JS^  •  dt  gB.  dont^f  r  sg_f  lag 


•  oeu  vslue  selsctsd 

-  PAUSE; 

-  FALSE; 
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toJSNP.  dtga.  fragMnt^of f 0« t  : 
tOjSNP  •  dtf««  t 

•  dtg««  protocoT  I 


toJSHP  •  dtga.  8ourc«^0ddr 
to_S  NP  •  d  t  dM  t  InAt  loa^oddr  t 
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-  0; 

-  60; 

*  this  Quabsr  vill  bs  ss- 
slfnsd  bj  ths  DoO  Bxsoutivs 
Afsut  for  Protocols; 

*  ststt^fsetor.hssdtr.dssti* 
ostio^sddr; 

*  ststs  Ttetor.hssdsr.soures 
sddr;“ 


—If  ths  frsgaent  rseslvsd  Is  ths  first  frsgasBti  thsa  ths 
*^ts  ssetioa  esrriss  ths  ICMP  srror  Msssgs,  ths  hssdsr  of  ths 
— tiasd-out  dstsgrsa,  sod  its  first  64  bytss  of  dsts*  If  frsr* 
-^sat  tsro  is  aot  sssilsbls  then  no  tias  ssessdsd  assd  bs  seat 

—St  sll. 


toJSIIP«dtfa«dsts(0]:  •  12;  —ICMP  typs  *  Tios  Bxcssdsd 
tQrsV«dtfa«dsts(l]:  •  1;  —Cods  •  fregosat  rsssssably 
""  tiosout 

— <opy  ia  ths  tiosd-out  dstsgrso's  hssdsr  plus  ths  first 
•^4  bytss  of  its  dsts  ssetioa  (sssuasd  to  bo  of  Isngth  ”11*)* 

to_8MP*dtfo«dsts[8**IH*3]  ststs_fsetortO.*il-*l ) ; 

to3sv^«8tga*totsl_lsagth  to_SI9*hssdsr_Isafth*4  M  >  8; 

co^ttts^icap^chseksuo;  "" 

— Cooputs  dstsgrso's  hssdsr  chscksoa*  dstsvaias  ths  routs  for 
—ths  dstsgrso,  the  typs  of  ssnrles  iadicstors,  sad  ths 
Wstsgrso  siss  for  ths  SUP* 

ceoputs^chscksuo; 

to^SIIP*typs  efjisrvies  iadicstors  :•  0; 
to^W •  IsngDi  T«  toJII#'*  dtgo.  cot sl^lsngt h; 
routs; 

^Hlsqusst  ths  OBscutloa  sasiroaosat  to  pass  ths  eoatsats  of 
— toJSNP  to  ths  locsi  subost  protocol  for  ersnsoissioa* 

TtAMSPSt  toJSNP  to  ths  SUP. 

9* 4. 6* 3* 12  Ksoots  dslivsry.  Ths  rsaots^dslivsry  procedure  dscoaposss  s 
dscsgrso  sr riving  ^roa  s  rsoots  IP  Into  iKsrfscs  psrsascsrs  sad  dsts  sad 
deli vers  thsa  to  the  dsstlastioa  ULP,  Ths  dsts  offsets  of  this  procedure 

srs: 


s*  Dsts  oxsaXnsd: 

f  roaJSMP  •  dtga.  sourcsjsddr 
froaJIKP • dtga*  dost last ioa^sddr 
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f  roB^SlIP  •  dtga*  protocol 

ofjMnrleo 

f  roBjSNf  •  dtfs.  tot  J^lsQf  th 
f  r  oa_SlP  •  dtfs.  hosds^lsngt  h 
frooJ5IIP.dtf«*dsts  * 
f  r  •  ^tgm*  opt  lout 

b.  Dsto  modlflodt 


to  UIF.dsstlnstlon^sddr 
toTjHiF  •  sourcs^oddr"* 
toTUlF  «protoMl 
co3njP*tppo  of  oonrleo 


to  ULF.Isogth 
to*ln.P*dsts 


to  ULP.dsstlMtlon  sddr: 


tcHjLP .  soures^oddr"*  : 

to3flF*protoMl  t 

toJJtr.typo^of^^sonrleo  t 

tojffl?  •  IsogTh  “  : 

toJULP.dsts  t 

to3^*optioQS 


•  fro«JIIIP.dtf«*dootlBotleB^sddr; 

•  fr0BjBV.dtgB.8oure«_sddrT 

•  fro«^8l9.dtga.protoMl; 

•  froBjSHP«dtCB«t7p«  of^sorrleo; 

*>  froo~81IP.dtf«*tot  J  ISQgth  * 

itmJW  m  dtgB«  bii«dsr_loagtb*4 ; 
-  froBjlMF.dtgB.dsts!  ~ 

•  fros^SMP.dtfs.  opt  loss; 


i 

»  * 

%* 

I 

* 


NOTE:  Tht  Const  of  ths  toJJLF  olsBists  Is  uBSpselfisd.  sllonliig  ss  laplr- 
Btutor  to  ssslgn  dstT  typsa  for  tbs  Intsrfses  psrsBstsco.  If  tboss 
dsts  typss  dlffsr  froB  tbs  IF  bssdsr  tppss,  tbs  ssslgoasst  ststsasBts 
sbovt  bscoBs  typs  coorsfiloas. 


9.4.6.3.13  touts.  Tbs  routs  proosdurs  sksbIoss  tbs  dostisstios  sddrsss 
sod  options  f Iti^  of  SB  outbound  dstsgrsB  in  toJIV  to  dstsndBS  s  locsl 
dsstlnstloB  sddrsss.  Tbs  dsts  tffsets  of  this  proosdurs  srsi 

s.  Dsts  sxsBlBsd: 

toJINP .  ^gB.  dsstlBstioBjiddr 
to^NP.dtgB.  options  ** 

b.  Dsts  Bodifisd; 

to^SMF .  loesl^dsstiBstioBjiddr 
toJIMP.dtgB*  opt  ions  ^ 

Tbs  procsdurs: 

if  (tOjSXP.dtgB.  opt  ions  iBCludsS  tiBSStSBp) 
tbsn 

if  (ths  BSatt  tiBSStSBp  field  is  tO^SHP.dtgB.  opt  ions  .tiBSStSS^ 
is  STsilsbIs) 

then 
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—The  timestamp  or  address/tlmestamp  pair  is  inserted  in 
— the  next  field  in  to_SNP.dtgm.optlopa. timestamp, 
end  if; 
end  if; 

if  (the  network  id  field  of  destination  matches  the  network  id 
of  the  local  subnet  protocol  ) 

then  ^  , 

— Tramlate  the  REST  field  of  destination  into  the  subnetwork 

—address  of  the  destination  on  this  subnet. 

—implementation  dependent  action 

else 

If  ( to JSNP.dtgm. options  Includes  security) 
then 

—Find  the  appropriate  gateway  with  security  level  equal  to 
—•the  security  level  of  to_^SNP.dtgm. options. security.  If 
—none  exists,  send  error  message, 
end  if; 

if  (to  SNP.dtgm.optiotm  includes  loose  source  and  record  routing) 

^*'*if  (the  network  Id  field  of  next  gateway  in  to_SNP.dtgm.option. 
loose^source  matches  the  network  of  the  local  subnet 
proto'col) 

then 

—The  gateway  address  (as  known  in  the  eavlroment  into 
—which  the  datagram  is  being  forwarded)  replaces  the 
—the  network  id  field  of  next  gateway  in  to_SNP.dtgm 
— .  options,  loose^source 
end  if; 
end  if; 

if  (to  SNP.dtgm. opt ions  includes  strict  source  and  record  routing) 
then 


if  (the  network  id  field  of  next  gateway  In  to_SNT -dtgm. option. 
strict__source  matches  the  network  of  the  local  subnet 
protocol) 

then 

— ^The  gateway  address  (as  known  in  the  environment  into 
—which  the  datagram  is  being  forwarded)  replaces  the 
— the  network  id  field  of  next  gateway  in  to  JSNP.dtgm 
— .  opt  ions .  s  t  r  ict__^eour  ce . 

else 

—The  datagram  cannot  be  forwarded  and  error  message  sent, 
end  if; 
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If  (to^SNP.dtgm. options  includes  record  routing) 
then 

if  (the  next  record  route  field  in  toJSflP.dtgn,  options  •record 
routing  is  available) 

then 

— The  gateway  address  (as  known  in  the  environment  into 
—which  the  datagram  is  being  forwarded)  replaces  the 
—next  record  route  field  in  to_SNP.dtgm* options. record^ 
— routing.  “ 

end  if; 
end  if; 
end  if; 

—Set  the  local  destination  interface  parameter. 

to  SNP. local  destination  addr  :■  (subnetwork  address  found  above) 
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10.  EXECUTION  ENVIRONMENT  REQUIREMENTS 

10.1  Description.  This  section  describes  the  facilities  required  of  an 
execution  environment  for  proper  Implementation  and  operation  of  the  Internet 
Protocol 4  Throughout  this  document,  the  environmental  model  portrays  each 
protocol  as  an  Independent  process.  Within  this  model,  the  execution  environ¬ 
ment  must  provide  two  facilities:  Interprocess  communication  and  timing. 

10.2  Interprocess  communication.  The  execution  environment  must  provide 
an  Interprocess  communication  facility  to  enable  Independent  processes  to 
exchange  variable- length  units  of  information,  called  messages.  For  IP's 
purposes,  the  IPC  facility  la  not  required  to  preserve  the  order  of  messages. 
IP  uses  the  IPC  facility  to  exchange  Interface  parameters  and  data  with 
upper  layer  protocols  across  Its  upper  Interface  and  the  subnetwork  protocol 
across  the  lower  Interface.  Sections  6  and  8  specify  these  Interfaces. 

10.3  Timing.  The  execution  environment  must  provide  a  timing  facility 
that  maintains  a  real-time  clock  with  units  no  coarser  than  1  millisecond. 

A  process  must  be  able  to  set  a  timer  for  a  specific  tine  period  and  be 
informed  by  the  execution  environment  when  the  time  period  has  elapsed. 

A  process  must  also  be  able  to  cancel  a  previously  set  timer.  Two  IP 
mechanisms  use  the  timing  facility.  The  Internet  timestamp  carries  timing 
data  In  mllllsecood  units.  The  reassembly  mechanism  uses  timers  to  limit 
the  lifetime  of  a  datagram  being  reassembled.  In  the  mechanism  specification 
this  facility  Is  called  TIMEOUT. 
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APPENDIX  A  -  DATA  TRANSMISSION  ORDER 


The  order  of  transalssioa  of  the  header  and  data  described  in  this  docunent 
is  resoled  to  the  octet  level*  Whenever  a  diagram  shows  a  group  of  octets, 
the  order  of  transmission  of  those  octets  is  the  normal  order  in  which  they 
are  read  in  English*  For  example,  in  the  following  diagram  the  octets  are 
transmitted  in  the  order  they  are  numbered* 

0  12  3 
012345678S01234B678901234667B901 
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DEPARTHENT  OF  DEFENSE 
WASHINGTON,  D.C.  20301 

Tr«nsiiltslon  Control  Protocol 

MIL-STD-1778 

1.  This  Military  Standard  is  approved  for  use  by  all  Departments  and 
Agencies  of  the  Department  of  Defense. 

2.  Beneficial  comments  (recommendations,  additions,  deletions)  and  any 
pertinent  data  %^ich  may  be  of  use  in  improving  this  document  should  be 
addressed  to:  Defense  Communications  Agency,  ATTN:  JllO,  1860  Wlehle 
Avenue,  Reston,  Virginia  22090,  by  using  the  self- addressed  Standardltatlon 
Document  Improvement  Proposal  (DD  Form  1426)  appearing  at  the  end  of  this 
document,  or  by  letter. 
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FOREWORD 

This  document  specifies  the  Transmission  Control  Protocol  (TCP),  a  reliable 
connection-oriented  transport  protocol  for  use  in  packet-switched  communica¬ 
tion  networks  and  internetworks.  The  document  includes  an  overview  with  a 
model  of  operation,  a  description  of  services  offered  to  users,  and  a  de¬ 
scription  of  che  architectural  and  environmental  requl reraents.  The  nrctocoi 
service  interfaces  and  .mechanisms  are  specified  using  an  e::tended  state 
machine  model. 
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1.  SCOPE 

1.1  Purpose.  This  standard  establishes  criteria  for  the  Transmission  Con¬ 
trol  Protocol  (TCP),  a  reliable  connection-oriented  transport  protocol  for 
use  in  packet-switched  and  other  coamunlcation  networks  and  interconnected 
sets  of  such  networks. 

1.2  Organization.  This  standard  is  organized  Into  ten  paragraphs.  Begin¬ 
ning  with  paragraph  4,  the  TCP's  role  is  established  in  the  evolving  DoD 
protocol  architecture  and  the  TCP's  major  services  and  mechanisms  are  also 
introduced.  Paragraphs  5  and  6  more  formally  specify  the  services  TCP  offers 
to  upper  layer  protocols  and  the  interface  through  which  those  services 

are  accessed.  Similarly,  paragraphs  7  and  8  specify  the  services  required 
of  the  lower  layer  protocol  and  the  lower  interface.  Paragraph  9  specifies 
the  mechanisms  supporting  the  TCP  services  and  paragraph  10  outlines  the 
functionality  required  of  the  execution  environment  for  successful  TCP 
operation. 

1.3  Application.  The  Transmission  Control  Protocol  (TCP)  and  the  Inter¬ 
net  Protocol  (IP)  are  mandatory  for  use  In  all  DoD  packet  switching  networks 
which  connect  or  have  the  potential  for  utilizing  connectivity  across  network 
or  subnetwork  boundaries.  Network  elements  (hosts,  front-ends,  bus  interface 
units,  gateways,  etc.)  within  such  networks  which  are  to  be  used  for  inter¬ 
netting  shall  implement  TCP/IP.  The  term  network  as  used  herein  Includes 
Local  Area  Networks  (LANs)  but  not  Integrated  weapons  systems.  Use  of  TCP/IP 
within  LANs  Is  strongly  encouraged  particularly  where  a  need  is  perceived  for 
equipment  interchangeability  or  network  survivability.  Use  of  TCP/IP  in 
weapons  systems  is  also  encouraged  where  such  usage  does  not  dlnvinish  network 
performance. 
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2.  REFERENCED  DOCUMENTS 


2.1  Issues  of  documents.  The  following  docui^ncs  of  the  issue  in  effect 
on  date  of  invitation  for  bids  or  request  for  proposal,  form  a  part  of  this 
standard  to  the  extent  specified  herein.  (The  provisions  of  this  paragraph 
are  under  consideration.) 


2.2  Other  publications.  The  following  docuiaents  form  a  part  of  this 
standard  to  the  extent  specified  herein.  Unless  otherwise  indicated,  the 
issue  in  effect  on  date  of  invitation  for  bids  or  request  for  proposals  shall 
apply.  (The  provisions  of  this  paragraph  are  under  consideration.) 
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3.  DEFINITIONS 

3.1  Definition  of  terns.  The  definition  of  terns  used  in  this  stan^rd 
ghall  comply  with  FED-sfFl037.  Terse  and  definitions  unique  to  MIL-STD-1778 
are  contained  herein. 

a.  Acknowledanent  Number.  A  32-blt  field  of  the  TCP  header  contaln- 
Ing  the  next  sequence  number  expected  by  the  sender  of  the  segment. 

b.  ACK.  Acknowledgment  flag:  a  control  bit  in  the  TCP  header  indicat¬ 
ing  that  the  acknowledgment  number  field  is  significant  for  this 
segment. 

c.  Checksum.  A  16-bit  field  of  the  TCP  header  carrying  the  one's 
complement  based  checksum  of  both  the  header  and  data  in  the 
segment. 

d.  connection.  A  logical  communication  path  identified  by  a  pair  of 
sockets. 

e.  datagram.  A  self-contained  package  of  data  carrying  enough  Infor- 
matlon  to  be  routed  from  source  to  destination  without  reliance 

on  earlier  exchanges  between*  source  or  destination  and  the  trans¬ 
porting  network. 

f.  datagram  service.  A  datagram,  defined  above,  delivered  in  such  a 
way  that  the  receiver  can  determine  the  boundaries  of  the  datagram 
as  it  was  entered  by  the  source.  A  datagram  is  delivered  with 
high  probability  to  the  desired  destination,  but  it  nay  possibly 
be  lost.  The  sequence  In  which  datagrams  are  entered  into  the 
network  by  a  source  is  not  necessarily  preserved  upon  delivery  at 
the  destination. 

«.  Data  Offset.  A  TCP  header  field  containing  the  number  of  32-blt 
words  in  the  TCP  header. 

h.  Destination  Address.  The  destination  address,  usually  the  network 
and  ho<t  i dent i idlers.  Although  not  carried  in  the  TCP  header,  this 
value  is  passed  to  ami  received  from  the  network  protocol  entity 
with  each  segment. 

I.  Destination  Port.  The  TCP  header  field  containing  a  2-octet  value 
Identifying  the  destination  upper  level  protocol  of  a  segment’s 

data. 

J.  EFfP.  Electronic  Pile  Transfer  Protocol.  Electronic  mall. 

K.  A  control  bit  of  the  TCP  header  Indicating  that  no  more  data 
will  be  sent  by  the  sender. 


1,  FTP.  File  Tranafer  Protocol 
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m.  header.  The  collection  of  control  Infomatlon  transnltted  with 
data  between  peer  entities. 

n.  host.  A  cooputer,  particularly  a  source  or  destination  of  messages 
from  the  point  of  view  of  the  communication  network. 

O’  Identification.  A  value  passed  with  each  segment  to  the  network 
protocol  entity  (Internet  Protocol).  This  identifying  value 
assigned  by  the  sending  TCP  aids  in  assembling  the  fragments  of 
a  datagram. 

p.  internetwork.  A  set  of  interconnected  subnetworks. 

9*  internet  address.  A  four  octet  (32  bit)  source  or  destination 
address  composed  of  a  Network  field  and  a  Local  Address  field. 

r.  internet  datagram.  The  package  exchanged  between  a  pair  of  IP 
modules.  It  is  made  up  of  an  Internet  header  and  a  data  portion. 

s.  Internet  Protocol 

t.  ISN.  The  Initial  Sequence  Number.  The  first  sequence  number  used 
for  either  sending  or  receiving  on  a  connection.  It  is  selected  on 
a  clock  based  procedure. 

local  network.  The  network  directly  attached  to  host  or  gateway. 

V.  M^.  Maximum  Segment  Lifetime,  the  time  a  TCP  segment  can  exist 
in  the  internet-work  system.  Arbitrarily  defined  to  be  2  minutes. 

w.  Options.  The  optional  set  of  fields  at  the  end  of  the  TCP  header 
used  in  a  SYN  segment  to  carry  the  maximum  segment  site  acceptable 
to  the  sender. 

pmcket  network.  A  network  based  on  packet-switching  technology. 
Messages  are  split  into  small  units  (packets)  to  be  routed  inde¬ 
pendently  on  a  store  and  forward  basis.  This  packetlrlng  pipelines 
packet  transmission  to  effectively  use  circuit  bandwidth. 

y*  Pmdding.  A  header  field  inserted  after  option  fields  to  ensure 
that  the  data  portion  begins  op  a  32-bit  word  boundary.  The  pad¬ 
ding  field  value  is  tero. 

r.  PUSH.  A  control  bdt  of  the  TCP  header  occupying  no  sequence  space, 
indicating  that  this  segment  contains  data  that  must  be  pushed 
through  to  the  receiving  ULP. 

^a.  push  service.  A  service  provided  by  TCP  to  the  upper  level  proto¬ 
cols.  A  push  directs  TCP  to  segment,  send,  and  deliver  data 
received  up  to  that  point  as  soon  as  flow  control  permits. 
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bb.  receive  next  sequence  number.  The  next  sequence  number  s  TCP  Is 
expecting  to  receive. 

cc.  receive  window.  This  represents  the  sequence  twmbers  s  TCP  Is 
willing  to  receive.  Thus,  the  TCP  considers  that  segments  over¬ 
lapping  the  rai«e  RECVJJEXT  to  RECVJ«EXT  +  RECVJrfND  -  1  carry 
acceptable  data  or  conTrol.  SegmenTs  containing  sequence  numbers 
entirely  outside  of  tnls  range  are  considered  duplicates  and  dis¬ 
carded. 

dd.  Reserved.  A  6-blt  field  of  the  TCP  header  that  Is  not  currently 
used  but  must  be  sero. 

ee.  RST.  A  control  Mt  of  the  TCP  header  Indicating  that  the  connec¬ 
tion  associated  irith  this  segment  Is  to  be  terminated. 

ff,  segment.  The  unit  of  data  exchanged  by  TCP  modules.  This  tens 
may  also  be  used  to  describe  the  unit  of  exchange  between  any 
transport  protocol  modules. 

segment  length.  The  amount  of  sequence  number  space  occupied  by 
segment.  Including  any  controls  which  occupy  sequence  space. 

hh.  send  sequence.  This  Is  the  next  sequence  number  the  TCP  will  use 
to  send  data  on  the  connection.  It  Is  Initially  selected  from  an 
Initial  sequence  lumber  curve  (ISN)  and  Is  Incremented  for  each 
octet  of  data  or  sequenced  control  transmitted. 

11.  send  window.  This  represents  the  sequence  lumbers  which  the 

remote  TCP  Is  willing  to  receive.  It  is  the  value  of  the  window 
field  specified  In  segtMnts  from  the  remote  (data  receiving)  TCP. 
The  range  of  new  sequence  numbers  which  may  be  emitted  by  a  TCP 
Ues  between  SEND_NEXT  aral  SENDJJNA  *►  SENDJWDW  -  1.  (Retrans¬ 
missions  of  sequence  numbers  between  SEND^UNA  and  SND__NEXT  are 
expected,  of  course.) 

Jj.  Sequence  Number.  A  32-blt  field  of  the  TCP  header  containing  the 
sequence  number  of  the  1)  a  sequenced  control  flag  (if  present), 
or  2)  the  first  byte  of  data  (If  present),  or,  3)  for  empty  seg¬ 
ments.  the  sequence  number  of  the  next  data  octet  to  be  sent. 

socket.  An  address  which  specifically  Includes  a  port  identifier, 
that  Ts ,  the  concatenation  of  an  Internet  Address  with  a  TCP  port. 

ll.  Source  Port.  The  TCP  header  field  containing  a  2-octet  value 

identifying  the  source  upper  level  protocol  of  a  segment’s  data. 

mm.  TCP  segment.  The  package  exchanged  between  TCP  modules  made  up 
of  the  TCP  header  and  a  text  portion  (which  may  be  empty). 

nn.  UDP.  User  Datagram  Protocol 


1-165 
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00.  ULP.  Upper  Level  Protocol:  sny  protocol  sbove  TCP  in  the  Isyered 
protocol  hierarchy  that  uses  TCP.  This  terra  Includes  presentation 
layer  protocols »  session  layer  protocols,  and  user  applications* 

pp.  Urgent  Pointer.  A  TCP  header  field  containing  a  positive  offaet 
to  the  sequence  lumber  of  the  segment  indicating  the  position  of 
urgent  data  In  the  connection's  data  stream.  This  field  Is 
valid  only  when  the  URG  flag  Is  on. 

qq.  URG.  A  control  bit  of  the  TCP  header  Indicating  that  the  urgent 
field  contains  a  valid  pointer  to  urgent  Information  In  the 
connection's  data  stream. 

rr.  Window.  A  2’-octet  field  of  the  TCP  header  Indicating  the  lumber 
of  data  octets  (relative  to  the  acknowledgment  number  In  the 
header)  that  the  segment  sender  Is  currently  willing  to  accept. 
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4.  GENERAL  REQUIREMENTS 

.2221.*  goal  of  this  stsndard  Is  to  avoid  assualng  a  particular 

systea  coof Iguratlon.  As  a  practical  natter,  the  distribution  of  protocol 
layers  to  specific  hardware  configurations  will  vary.  For  example,  many 
computer  systems  are  connected  to  networks  via  front-end  computers  trhlch 
house  TCP  and  lower  layer  protocol  software.  Although  appearing  to  focus  on 
TCP  Implementations  which  are  co-resident  with  the  upper  and  lower  layer 
protocols,  this  specification  can  apply  to  any  configuration  given  appropriate 
Inter-layer  protocols  to  bridge  hardware  boundaries. 

4.2  TCP  defined.  TCP  Is  designed  to  provide  reliable  communication  between 
pairs  of  processes  in  logically  distinct  hosts  on  networks  and  sets  of  In¬ 
terconnected  networks.  Thus,  TCP  serves  as  the  basis  for  DoD-vlde  Inter-process 
communication  In  communication  systems.  TCP  will  operate  successfully  In  an 
environment  where  the  loss,  damage,  duplication,  or  mlsorder  data,  and  network 
congestion  can  occur.  This  robustness  in  spite  of  unreliable  communications 
media  makes  TCP  well  suited  to  support  military,  governmental,  and  commercial 
applications.  TCP  appears  In  the  DoO  protocol  hierarchy  at  the  transport 
layer.  Here,  TCP  provides  connection-oriented  data  transfer  that  Is  reliable, 
ordered,  full-duplex,  and  flow  controlled.  TCP  Is  designed  to  support  a  wide 
range  of  upper  layer  protocols  (ULPs).  The  ULPs  can  cl«annel  contlmious  streams 
of  data  through  TCP  for  delivery  to  peer  ULPs.  TCP  breaks  the  streams  into 
portions  which  are  encapsulated  together'wlth  appropriate  addressing  and 
control  Information  to  form  a  segment — the  unit  of  exchange  between  peer  TCPs. 

In  turn,  TCP  passes  segments  to  the  network  layer  for  transmission  through  the 
communication  system  to  the  peer  TCP. 


HOST  INTtaNf  T  PSOTOCOl 


SUSHI  TwosK  eaoTocoi 
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A. 3  Network  layer  provisions.  The  network  leyer  provides  for  date  transfer 
between  hosts  attached  to  a  cooununicatlon  aystea.  Such  systeas  aay  range  froa 
a  single  network  to  interconnected  sets  of  networks  forming  an  Internetwork. 

The  ainiauB  required  data  transfer  service  is  Halted;  data  aay  be  lost,  dupli* 
Gated,  aisordered,  or  daaaged  in  transit.  As  part  of  the  transfer  service 
though,  the  network  layer  must  provide  global  addressing,  handle  routing, 
anl  hide  network's peciflc  characteristics.  As  a  result,  upper  layer  protocols 
(including  TCP)  using  the  network  layer  aay  operate  above  a  wide  spectrua  of 
subnetwork  systeas  ranging  froa  hard-wlre  connection!;  to  packs t'switched 
or  circuit-switched  subnets.  Additional  services  the  network  layer  aay 
provide  Include  selectable  levels  of  transmission  quality  such  as  precedence, 
reliability,  delay,  and  throughput.  The  network  layer  also  allows  data 
labelling,  needed  in  secure  environments,  to  associate  security  information 
%!ith  data. 

TCP  design.  TCP  was  specifically  designed  to  operate  above  the  Inter¬ 
net  Protocol  (IP)  which  supports  the  interconnection  of  networks.  IP's  inter¬ 
net  datagram  service  provides  the  functionality  described  above.  Originally, 
TCP  and  IP  were  developed  as  a  single  protocol  providing  resource  sharing 
across  different  packet  network!^.  The  need  for  other  transport  protocols  to 
use  IP's  services  led  to  their  specification  as  two  distinct  protocols. 

A. 5  TCP  mechanisas.  TCP  builds  Its  services  on  top  of  the  network  layer's 
potentially  unreliable  ones  with  aechaiflsas  such  as  error  detection,  positive 
acknowledgments,  sequence  isiabers,  and  flow  control.  These  mechanisms  require 
certain  addressing  and  control  information  to  be  initialised  and  aaintained 
during  data  transfer.  This  collection  of  information  is  called  a  TCP  connec¬ 
tion.  The  following  paragraphs  describe  the  purpose  and  operation  of  the 
major  TCP  mechanisas. 

A. 5,1  PAP  mechanism.  TCP  uses  s  positive  acknowledgement  with  retransmis¬ 
sion  (PAR)  mechinisa  to  recover  froa  the  loss  of  s  segment  by  the  lower 
layers.  The  strategy  with  PAR  is  for  a  sending  TCP  to  retransalt  a  segment 
at  timed  Intervals  until  a  positive  acknowledgement  Is  returned.  The  choice 
of  retransmission  Interval  affects  efficiency.  An  interval  that  is  too 
long  reduces  data  throughput  %!hile  one  that  Is  too  short  floods  the  transmis' 
Sion  aedla  with  superfluous  segments.  In  TCP,  the  timeout  Is  expected  to  be 
dynamically  adjusted  to  approximate  the  segment  round-trip  time  plus  a  factor 
for  Internal  processing,  otherwise  performance  degradation  may  occur.  TCP 
uses  a  simple  checksum  to  detect  segments  daaaged  in  transit.  Such  segments 
are  discarded  without  being  acknowledged.  Hence,  damaged  segments  are  created 
identically  to  lost  segments  and  are  compensated  for  by  the  PAR  mechanism. 

TCP  assigns  sequence  mmbers  to  identify  each  octet  (an  eight  bit  byte)  of 
the  data  stream.  These  enable  a  receiving  TCP  to  detect  duplicate  and  out- 
of-order  segments.  Sequence  ouabers  sre  also  used  to  extend  the  PAR  mechsnlta 
by  sllowlng  s  single  acknowledgment  to  cover  many  segments  worth  of  data. 

Thus,  s  sendir^  TCP  can  still  send  new  data  although  previous  data  has  not 
been  acknowledged. 


8 
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4.5.2  Flov  control  mechsnlta,  TCP’s  flow  control  isechsnlsii  enables  s 
receiving  TCP  to  govern  the  aaount  of  date  dispatched  by  a  sending  TCP.  The 
mechanisn  is  based  on  a  "window*  %#hich  defines  a  contiguous  interval  of 
acceptable  sequence  nuabered  data*  As  data  is  accepted,  TCP  slides  the 
window  upward  in  the  sequence  nuabcr  space.  This  window  is  carried  in 
every  segment  enabling  peer  TCPs  to  aaintain  up*to-date  window  infoniation. 

4.5.3  Multiplexing  aechanisa.  TCP  employs  a  multiplexing  mechanism  to 
allow  multiple  ULPs  within  a  single  host  and  multiple  proccesaes  in  a  ULP  to 
use  TCP  simultaneously.  This  mechanism  associates  identifiers,  called  ports, 
to  ULP's  processes  accessing  TCP  services.  A  ULP  connection  is  uniquely  iden¬ 
tified  with  a  socket,  the  concatenation  of  a  port  and  an  internet  address. 

Each  connection  is  uniquely  named  with  a  socket  pair*  This  naming  scheme 
allows  a  single  ULP  to  support  conntetiona  to  multiple  remote  ULPs.  ULPs 
which  provide  popular  resources  are  assigned  permanent  sockets,  called  well-* 
known  sockets* 

4.6  ULP  synchronisation.  When  two  ULPs  wish  tc  ccmmmicate,  they  instruct 
their  TCPs  to  initialise  and  synchronise  the  mechanism  information  on  each 
to  open  the  connection.  However,  the  potentially  unreliable  network  layer 
can  complicate  the  process  of  synchionisation.  Delayed  or  duplicate  segments 
from  previous  connection  attempts  might  be  mistaken  for  new  ones.  A  handshake 
procedure  with  clock  based  sequence  numbers  is  used  in  connection  opening  to 
reduce  the  possibility  of  such  false  connections.  In  the  simplest  handshake, 
the  TCP  pair  synchronises  sequence  nunber;^  by  exchanging  three  segments, 
thus  the  name  three-way  handshake*  The  scenario  following  the  overview 
depicts  this  exchange.  The  procedure  will  be  discussed  more  fully  in  the 
mechanism  descriptions.  Paragraph  9.2, 

ULP  modes*  A  ULP  can  open  a  connection  in  one  of  two  modes,  passive 
or  active*  With  a  passive  open  a  ULP  instructs  its  TCP  to  be  "receptive" 
to  connections  with  other  ULPs*  With  ar  active  open  a  ULP  instructs  its 
TCP  to  actively  initiate  a  three-way  handshake  to  connect  to  another  ULP. 
Usually,  an  active  open  is  targeted  to  a  passive  open.  This  active/passive 
model  supports  server-oriented  applications  where  a  permanent  resource, 
such  as  a  data-base  management  process,  can  always  be  accessed  by  remote 
users.  However,  the  three-way  handshake  also  coordinates  two  slmultanecxis 
active  opens  to  open  a  connection.  Over  an  open  connection,  the  ULP-palr 
can  exchange  a  continuous  stream  of  data  in  both  directions.  Normally,  TCP 
transparently  groups  the  data  into  TCP  segments  for  transmission  at  Its  own 
convenience*  However,  s  ULP  can  exercise  a  "push*  service  to  force  TCP  to 
package  and  send  data  passed  up  to  that  point  without  waiting  for  additional 
data*  This  mechanlsui  is  Intended  to  prevent  possible  deadlock  situations 
where  a  ULP  waits  for  data  internally  buffered  by  TCP.  for  example,  an 
Interactive  editor  might  wait  forever  for  a  single  Input  line  from  a  terminal* 
A  push  will  force  data  through  the  TCPs  to  the  awaiting  process.  TCP  also 
provides  a  means  for  a  sending  ULP  to  indicate  to  a  receiving  ULP  that 
"urgent"  data  appears  In  the  upcoming  data  stream.  This  urgent  mechanism 
can  support,  for  example.  Interrupts  or  breaks.  When  data  exchange  Is  com¬ 
plete  the  connection  can  be  closed  by  either  ULP  to  free  TCP  resources  for 
other  connections.  Connection  closing  can  happen  In  two  ways.  The  first. 
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called  a  graceful  close »  is  based  on  the  three-way  handshake  procedure  to 
complete  data  exchange  and  coordinate  closure  between  the  TCPs.  The  second, 
called  an  abort,  does  not  allow  coordination  and  way  result  in  loss  of  un¬ 
acknowledged  data. 

A. 8  Scenario.  The  following  scenario  provides  a  walk-through  of  a  connec¬ 
tion  opening,  data  exchange,  and  a  connection  closing  as  night  occur  between 
the  data  base  aanagement  process  and  user  Mentioned  above.  The  scenario 
flosses  over  aany  details  to  focus  on  the  three-way  handshake  nechar.lsa  In 
connection  opening  and  closlngt  and  the  positive  acknowledgaent  with  retrans- 
nlsslon  nechanlsa  supporting  reliable  data  transfer.  Although  not  pictured, 
the  network  layer  transfers  the  Infomatlon  between  the  TCPs.  For  the  purposes 
of  this  scenario,  the  network  layer  Is  assuaed  not  to  daaage,  lose,  duplicate, 
or  change  the  order  of  data  unless  explicitly  noted.  The  scenario  is  organ¬ 
ised  into  three  parts: 


a.  A  simple  connection  opening  In  steps  1-7. 

b.  Two-way  data  transfer  In  steps  8-17. 

c.  A  graceful  connection  close  In  steps  18-25. 


A. 9  Scenario  notation.  The  following  notation  is  used  In  the  diagrams: 


<—  SEQ#  200  <— 
“>  ACK#  201  — > 

A 

stub  DATA 


DELIVER  DATA 


V 


depicts  Information  exchange 
bct#een  peer  TCPs 
depicts  Information  passli^ 
across  the  Interface  between 
a  ULP  anl  Its  TCP 


riCviRE  2a.  a  simple  connection  opening. 

a.  ULP  B  (the  DB  manager)  Issues  a  PASSIVE  OPEN  to  TCP  B  to  prepare 
for  connection  attempts  from  other  ULPs  In  the  system, 

b.  ULP  A  (the  user)  Issues  an  ACTIVE  OPEN  to  open  a  connection  to 
ULP  8. 

c.  TCP  A  sends  a  segment  to  TCP  B  with  an  OPEN  control  fUf,  called  a 
STti,  carrying  the  first  sequence  number  (shown  as  SEQP200)  It  will 
use  for  data  sent  to  B, 
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d.  TCP  B  responds  to  the  SYN  by  sending  a  positive  acknowledgment, 
or  ACK,  marked  with  next  sequence  tumber  expected  from  TCP  A.  In 
the  same  segment,  TCP  R  sen^  its  o%m  SYN  with  the  first  sequence 
number  for  its  data  (SEQ#550). 

e.  TCP  A  responds  to  TCP  BU  SYN  with  an  ACK  showing  the  next  sequence 
number  expected  from  B. 

f.  TCP  A  now  informs  ULP  A  that  a  connection  is  wpen  to  UIP  B. 

g*  Upon  receiving  the  ACK,  TCP  B  Informs  ULP  B  that  a  connection  has 
been  opened  to  ULP  A. 


h.  ULP  A  passes  20  octets  of  data  to  TCP  A  for  transfer  across  the  open 
connection  to  ULP  B. 

1.  TCP  A  packages  the  data  in  a  segment  marked  with  current  ”A”  sequence 
number. 

j.  After  validating  the  sequence  number,  TCP  B  accepts  the  data  and 
delivers  it  to  ULP  B. 

k.  TCP  B  acknowledges  all  20  octets  of  data  with  the  ACK  set  to  the 
seqijence  number  ot  the  next  data  octet  expected. 
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FIGURE  3B.  Twcr-vay  date  transfer. 

l.  ULP  B  passes  125  bytes  of  (^aua  to  TCP  B  for  transfer  to  ULP  A. 

m.  TCP  B  packages  the  data  in  a  segment  marked  with  the  "B”  sequence 
number. 

n.  TCP  A  accepts  the  segment  and  delivers  the  data  to  ULP  A. 

0.  TCP  A  returns  an  ACK  of  the  received  data  marked  with  the  sequence 
number  of  the  next  expected  data  octet*  However,  the  segment  Is 
lost  by  the  network  and  never  arrives  at  TCP  B. 

p.  TCP  B  times  out  waiting  for  Che  lost  ACK  and  retransmits  the  segment. 
TCP  A  receives  the  retransmitted  segment,  but  discards  it  because 
the  data  from  the  original  segment  has  already  been  accepted.  How¬ 
ever,  TCP  A  re-sends  the  ACK. 

q.  TCP  B  gets  the  second  ACK, 


FIGURE  4a.  a  graceful  connection  close. 


r.  ULP  A  closes  Its  half  of  the  connection  by  issuing  a  CLOSE  to  TCP  A. 
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8.  TCP  A  sends  s  segment  marked  with  a  CLOSE  control  flag,  called  a 
FIN,  to  inform  TCP  B  that  ULP  A  will  send  no  more  data. 

t.  TCP  B  gets  the  FIN  and  informs  ULP  B  that  ULP  A  is  closing. 


FIGURE  4B.  A  graceful  connection  close. 

u.  ULP  B  completes  its  data  transfer  and  closes  its  half  of  the  connec¬ 
tion.  TCP  B  sends  an  ACK  of  the  first  FIN  and  its  own  FIN  to  TCP  A 
to  show  ULP  B's  closing.  TCP  A  gets  the  FIN  and  the  ACK,  then 
responds  with  an  ACK  to  TCP  B.  TCP  A  informs  ULP  A  that  the  connec¬ 
tion  is  closed.  (Not  pictured)  TCP  B  receives  the  ACK  from  TCP  A 
and  informs  ULP  B  that  the  connection  Is  closed. 
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5.  SERVICES  PROVIDED  TO  UPPER  LAYER 

This  section  describes  the  services  offered  by  the  Transmission 
Control  Protocol  to  upper  layer  protocols  (ULPs).  The  goals  of  this  section 
are  to  provide  the  motivation  for  protocol  mechanisms  and  to  provide  ULPs 
with  a  definition  of  the  functions  provided  by  this  protocol.  The  services 
provided  by  TCP  can  be  orgiinized  as  follows: 

a.  multiplexing  service 

b.  connection  management  services 

c.  data  transport  service 

d.  error  reporting  service 

5,2  Service  description.  A  description  of  each  service  follows. 

5.2.1  Multiplexing  service.  TCP  shall  provide  services  to  multiple  pairs 
of  processes  within  upper  layer  protocols.  A  process  within  a  ULP  using 
TCP  services  shall  be  Identified  with  a  ‘'port*'.  A  port>  when  concatenated 
with  an  Internet  address,  forms  a  socket  which  uniquely  names  a  ULP  through¬ 
out  the  internet.  TCP  shall  use  the  pair  of  sockets  corresponding  to  a 
connection  to  differentiate  between  multiple  users. 

5.2.2  Connection  management  service,.  TCP  shall  provide  data  transfer  capa¬ 
bilities,  called  connections,  between  pairs  of  upper  layer  protocols,  A  con¬ 
nection  provides  a  communication  channel  between  two  ULPs,  Characteristics 

of  data  transfer  are  specified  in  the  data  transfer  service  description. 
Connection  management  can  be  broken  into  three  phases;  connection  establish¬ 
ment,  connect  ion  maintenance ,  and  connection  termination. 

5.2.2, 1  Connection  establishment.  TCP  shall  provide  a  means  to  open  con¬ 
nections  between  ULP-palrs.  Connections  are  endowed  with  certain  properties 
that  apply  for  the  lifetime  of  the  connection.  Thr^e  properties,  Including 
security  and  precedence  levels,  are  specified  by  the  ULPs  at  connection 
opening.  Connections  can  be  opened  in  one  of  two  modes:  active  or  passive. 
TC?  shall  provide  a  means  for  a  ULP  to  actively  Initiate  a  connection  to 
another  ULP  uniquely  named  with  a  socket.  TCP  shall  establish  a  connection 
to  the  named  ULP  if: 

a.  no  connection  between  the  two  named  sockets  already  exists, 

b.  Internal  TCP  resources  are  sufficient, 

c.  the  other  ULP  exists,  and  has  simultaneously  executed  a  match¬ 
ing  active  open  to  this  ULP,  or  previously  executed  a  matching 
passive  open,  or  previously  executed  a  "global"  matching  pas¬ 
sive  open.  TCP  shall  provide  a  means  for  a  ULP  to  listen  for 
and  respond  to  active  opens  from  correspondent  ULPs.  Corre¬ 
spondent  ULPr.  are  named  In  one  of  two  ways: 

d.  fully  specified:  A  UIJ*  is  uniquely  named  by  a  socket.  A  con¬ 
nection  Is  established  when  a  matching  active  open  is  executed 
'as  described  above)  by  the  named  ULP. 
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e.  unspecified;  No  socket  Is  provided.  A  connection  is  estab¬ 
lished  with  any  ULP  executing  a  Hatching  active  open  naming 
this  ULP. 

5. 2. 2. 2  Connection  aaintenance.  TCP  shall  ?nalntaln  established  connections 
supporting  the  data  transfer  service  described  in  paragraph  3.2.3.  And,  TCP 
shall  provide  a  means  for  a  ULP  to  acquire  current  connection  status  with 
regard  to  connection  name,  data  transfer  progress,  and  connection  qualities. 

5. 2. 2. 3  Connection  termination.  TCP  shall  provide  a  means  to  terminate 
established  connections  and  nullify  connection  attempts.  Established  con¬ 
nections  can  be  terminated  in  two  ways: 

a.  Graceful  Close:  Both  UlPs  close  their  side  of  the  duplex  con¬ 
nection,  either  simultaneously  or  sequentially,  when  data  trans¬ 
fer  is  complete.  TCP  shall  coordinate  connection  termination 
and  prevent  loss  of  data  in  transit  as  promised  by  the  data 
transfer  service. 

b.  Abort:  One  ULP  itxlependently  forces  closure  of  the  connection. 
TCP  shall  not  coordinate  connection  termination.  Any  data  in 
transit  may  be  lost. 

5.2.3  Data  transport  service.  TCP  shall  provide  data  transport  over  estab¬ 
lished  connections  between  ULP-palrs.  The  data  transport  is  full-duplex, 
timaly,  ordered,  labelled  with  security  and  precedence  levels,  flow  controlled, 
and  err or- checked.  A  more  detailed  description  of  each  of  the  data  transport 
characteristics  follow. 

a.  full-d'jple*:  TCP  shall  support  simultaneous  bi-directional  data 
flow  between  the  correspondent  ULPs, 

b.  timely:  When  system  conditions  prevent  timely  delivery,  as 
specified  by  the  user  timeout,  TCP  shall  notify  the  local  ULP  of 
service  failure  and  subsequently  terminate  the  connection. 

c.  ordered:  TCP  shall  deliver  data  to  a  destination  ULP  in  the 
same  sequence  as  it  was  provided  by  the  source  ULP. 

d.  labelled:  TCP  shall  associate  with  each  connection  the  security 
and  precedence  levels  supplied  by  the  ULPs  during  connection 
establishment.  When  this  information  is  not  provided  by  the  ULP- 
palr,  TCP  shall  assume  default  levels.  TCP  shall  establish  a 
connection  between  a  ULP-palr  only  if  the  securlty/compartraent 
information  exactly  matches.  If  the  precedence  levels  do  not 
match  during  connection,  the  higher  precedence  level  is  associ¬ 
ated  with  the  connection. 

e.  flow  controlled:  TCP  shall  regulate  the  flow  of  data  across  the 
connection  to  prevent,  among  other  things,  internal  TCP  conges¬ 
tion  leading  to  service  degradation  and  failure. 
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f.  error  checked:  TCP  shall  deliver  data  that  is  free  of  errors 
within  the  probabilities  supported  by  a  simple  checksum. 

5.2.4  Capabilities  provided  to  ULPs  by  TCP.  TCP  shall  provide  two  capabi¬ 
lities  to  ULPs  concerning  data  transfer  over  an  established  connection:  data 
stream  push  and  urgent  data  signalling. 

a.  data  stream  push:  TCP  shall  transmit  any  waiting  data  up  to  and 
Including  the  indicated  data  portions  to  the  receiving  TCP  with¬ 
out  waiting  for  additional  data.  The  receiving  TCP  shall  deliver 
the  data  to  the  receiving  ULP  in  the  same  manner. 

b.  urgent  data  signalling:  TCP  shall  provide  a  means  for  a  s'^nding 
ULP  to  Inform  a  receiving  ULP  of  the  presence  of  significant,  or 
"urgent,"  data  in  the  upcoming  data  stream. 

5.2.5  Error  reporting  service.  TCP  shall  report  service  failure  stemming 
from  catastrophic  conditions  In  the  internetwork  environment  for  which  TCP 
cannot  compensate. 
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6.  UPPER  LAYER  SERVICE /INTERFACE  SPECIFICATIONS 

6.1  Goal.  The  goal  of  this  section  Is  to  specify  the  TCP  services  provided 
to  upper  layer  protocols  and  the  Interface  through  which  these  services  are  ac¬ 
cessed.  The  first  part  defines  the  interaction  primitives  and  Interface  param¬ 
eters  for  the  upper  interface.  The  second  part  contains  the  extended  state 
machine  specification  of  the  upper  layer  services  and  interaction  discipline. 

6.2  Interaction  primitives.  An  Interaction  primitive  defines  the  informa¬ 
tion  cxchar^ed  between  two  adjacent  protocol  layers.  Primitives  are  grouped 
into  two  classes  based  on  the  direction  of  information  flow.  Information 
passed  downward,  in  this  case  from  a  ULP  to  TCP,  is  called  a  service  request 
primitive.  Information  passed  upward,  from  TCP  to  the  UtP,  is  called  a 
service  response  primitive.  Interaction  primitives  need  not  occur  In  pairs. 
That  Is,  a  service  request  does  not  necessarily  elicit  a  service  "response"; 
a  service  "response"  may  occur  Independently  of  a  service  request. 

6.2.1  Interaction  primitive  categories.  The  information  associated  with 
an  interaction  primitive  falls  Into  two  categories:  parameters  and  data. 
Parameters  describe  the  data  and  indicate  how  it  is  to  be  treated.  The  data 
Itself  is  neither  examined  nor  modified.  The  format  of  the  parameters  and 
data  is  Implementation  dependent  and  therefore  not  specified.  TCP  implemen¬ 
tations  may  have  different  Interaction  primitives  imposed  by  the  execution 
environment  or  system  design  factors.  In  those  cases,  the  primitives  can  be 
modified  to  Include  more  Infonratlon  or  additional  primitives  can  be  defined 
to  satisfy  system  requirements.  However,  all  TCPs  must  provide  at  least  the 
information  found  In  the  Interaction  primitives  specified  below  to  guarantee 
that  all  TCP  Implementations  can  support  the  same  protocol  hierarchy.  Addi¬ 
tional  primitives  that  affect  the  protocol  mechanisms  may  not  be  used. 

6.3  Service  request  primitives.  The  TCP  service  request  primitives  enable 
connection  establishment,  data  transfer,  and  connection  termination.  The 
request  primitives  are: 

a.  Unspecified  Passive  Open, 

b.  Fully  Specified  Passive  Open, 

c.  Active  Open, 

d.  Active  Open  With  Data, 

e.  Send, 

f.  Allocate, 

g.  Close, 

k.  Abort,  and 

l.  Status. 

6. A  Parameter  descriptions.  A  de'«criptlon  and  list  of  paramet^'rs  for  each 
service  request  follows.  Optional  service  request  parameters  are  f-»lI)weJ  by 
“(opt lonal ] . " 

6.A.1  Unspecified  passive  open.  This  service  request  prlml:lve  allows  3 
ULP  to  listen  for  and  respond  to  connection  attempts  from  an  unnamed  ILF  At 
a  specified  security  aiid  precedence  level.  TCP  accepts  In  an  Vnspe:l:ie<i 
Passive  Open  at  least  the  following  Information: 
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«•  source  port 

b.  ULF  tine out  (optional] 

c.  ULP  timeout  action  [optional] 
d*  precedence  Toptional) 

e*  security^range  [optional] 

6.4,2  Fully  specified  passive  open.  This  service  request  prinitive  allows 
a  ULP  to  listen  for  and  respond  to  connection  attenpts  from  a  fully  naned 
ULP  at  a  particular  security  and  precedence  ^vel.  TCP  accepts  in  a  Fully 
Specified  Passive  Open  at  least  the  following  infomation: 

a.  source  port 

b.  destination  port 

c.  destination  address 

d.  ULP  titaeout  [optional] 

e.  ULP  timeout  action  [optional] 

f.  precedence  Toptional] 

g.  securlty^range  [optional] 

Active  open.  This  service  request  primitive  allows  a  ULP  to  initiate 
a  connection  attempt  to  a  named  ULP  at  a  particular  security  and  precedence 
level.  TCP  accepts  in  an  Active  Open  at  least  the  following  Information: 

a.  source  port 

b.  destination  port 

c.  destination  address 

d.  ULP  timeout  [optional j 

e.  ULP  1 1 me ou traction  [optional} 

f.  precedence  [optional] 

g.  security  [optional] 

6.^.4  Active  open  with  data.  This  service  request  primitive  allows  a  ULP 
to  initiate  a  connection  attempt  to  a  named  ULP  at  a  particular  security  and 
precedence  level  accompanied  by  the  specified  data.  TCP  accepts  in  an  Active 
Open  With  Data  at  least  the  following  information: 

a.  source  port 

b.  destination  port 

c.  destination  address 

d.  ULP  timeout  (optional] 

e.  ULP  timeout  actios:  [optional] 

f.  precedence  Toptional] 

g.  security  [optional] 

h.  data 

I.  data  length 

J.  PUSH  flag 
k.  imCEKT  flag 

Sg^d.  This  rervice  request  primitive  causes  data  to  be  transferred 
across  the  naned  connection.  TCP  accepts  in  a  Send  at  least  the  following 
Inf  onsat  Ion: 
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«•  local  connection  name 

b.  data 

c.  data  length 

d.  PUSH  flag 

e.  URGENT  flag 

f.  ULP  timeout  [optional] 

g.  ULP  time outpace ion  [optional] 

6.4.6  Allocate.  This  service  request  primitive  allows  a  ULP  to  issue  TCP 
an  incremental  allocation  for  receive  data.  The  parameter,  data  length,  is 
defined  in  sit^le  octet  units.  This  quantity  is  the  additional  number  of 
octets  which  the  receiving  ULP  is  wllUng  to  accept.  TCP  accepts  in  an 
Alloatte  at  least  the  following  information: 

a.  local  connection  name 

b.  data  length 

6.4.7  Close.  This  service  request  primitive  allows  a  ULP  to  indicate  that 
it  has  completed  data  transfer  across  the  named  connection.  TCP  accepts  in  a 
Close  at  least  the  following  information: 

a.  local  connection  name 

6.4.8  Abort.  This  service  request  primitive  allows  a  ULP  to  indicate  that 
the  named  c^n^ect ion  is  to  be  Immediately  terminated.  TCP  accepts  in  an  Abort 
at  lea«t  the  following  information: 

a.  local  connection  name 

6.4.9  Status.  This  service  request  primitive  allows  a  ULP  to  query  for  the 
current  status  of  the  na''^  connection.  TCP  accepts  in  a  Status  at  least  the 
following  information. 

a.  local  connection  name 

6.4.9. 1  Status  responses.  TCP  returns  the  requested  status  Information 
in  a  Status  Response,  defined  in  Section  6.4.10.7. 

6.4.10  Service  response  primitive;  Several  service  response  primitives 
are  provided  to  enable  TCP  to  infor'  user  of  connection  status,  data 
delivery,  connection  termination,  a  .  ‘^rror  condiciorw.  The  response  primi¬ 
tives  are  Open  Id,  Open  Failure,  Open  Success,  Deliver,  Closing,  Terminate, 
Status  Response,  and  Error.  Each  is  fully  defined  in  the  following  paragraphs. 

0p*»  This  service  response  primitive  informs  a  ULP  of  the 

local  connection  name  assigned  by  TCP  to  the  connection  requested  in  one  of 
the  previous  service  requests.  Unspecified  Open,  Fully  Specified  0p»en,  or  an 
Active  Open.  TCP  provides  in  an  Open  Id  at  least  the  following  information: 

a.  local  connection  name 

b.  source  port 

c.  destination  port  Ilf  known) 

d.  destination  address  (if  known) 
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6.4.10.2  Open  failure.  This  service  respo'.ise  primitive  informs  a  ULP 
the  failure  of  an  Active  Open  service  request,  TCP  provides  in  an  Open 
Failure  at  least  the  following  information: 

a.  local  connection  name 

6.4.10.3  Open  success.  This  service  response  primitive  informs  a  ULP 
the  completion  of  one  of  the  Open  service  requests.  TCP  provides  in  an 
Open  Success  at  least  the  following  information: 

a.  local  connection  name 

6.4.10.4  Deliver.  This  service  response  primitive  informs  a  ULP  of  tl 
arrival  of  data  across  the  named  connection.  TCP  provides  in  a  Deliver  i 
least  the  following  information: 

a.  local  connection  name 

b.  data 

c.  data  length 

d.  URGENT  flag 

6.4.10.5  Closing.  This  service  response  primitive  informs  a  IHJ  that 
peer  ULP  has  issued  a  CLOSE  service  request.  Also*  TCP  hat  delivered  al 
data  sent  by  the  remote  ULP.  TCP  provides  in  a  Closing  at  least  the  fol 
information: 

a.  local  connection  name 

6.4.10.6  Terminate.  This  service  response  primitive  informs  a  ULP  th. 
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J.  amount  of  data  in  octets  pending  receipt  by  the  local  ULP 

k.  urgent  state 

l.  precedence 
a.  security 

a.  ULP  timeout 

6.4. 10.8  Error*  This  service  response  pritsitive  informs  a  ULP  of  illegal 
service  requests  relating  to  the  named  connection  or  of  errors  relsting  to 
the  enviroment*  TCP  provides  In  an  Error  response  at  least  the  following 
information: 

a*  local  connection  name 
b*  error  description 

6*5  Extended  state  machine  specification  services  provided  to  upper  layer 


TCP  performs  in  a  distributed  environment.  Hence,  an  effective  model  of  TCP 
servtcei  c-«n  be  conef»^*cte4  through  the  composition  of  two  extended  state 
machines,  called  local  service  machines.  Figure  5  shows  a  summary  of  this 
"split-state*  model.  Each  local  machine  Is  coupled  with  one  ULP  of  the 
ULP-pair.  Each  ULP  provides  stimuli  to  Its  local  service  machine.  In  the 
form  of  service  requests,  and  receives  the  resulting  reactions,  as  service 
responses.  Each  local  machine  nmlntalns  a  jiomplete  state  record,  called  a 
state  vector,  maintaining  s  local  perBpe.ctlve  of  the  state  of  the  connection 
At  undetermined  Intervals,  t!ie  local  machines  exchange  Information  (denoted 
by  EXQiANGE),  thus  modelling  communication  delay.  An  extended  state  machine 
definition  is  composed  of  a  machine  idenrlfier,  a  state  diagram,  a  state 
vector,  a  set  of  data  scructures,  an  event  list,  and  an  events  and  actions 
correspondence* 
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6.5.1  Machine  Instantiation  Identlfiern  Each  local  aer/ice  aachine  it 
uniquely  identified  by  the  values: 

a.  port  of  ULP  A 

b.  address  of  ULP  A 

c«  port  of  ULP  B 

d.  address  of  ULP  B 

6.5. 1.1  Local  connection  naiie.  After  the  first  open  service  request »  a 
TCP  uses  a  shorter  naoe,  called  a  local  connection  naae,  to  identify  a  con¬ 
nection  in  the  interactions  %d.th  its  coresident  ULP.  The  Unspecified  Passive 
Open  service  request  does  not  designate  the  port  and  address  of  the  remote 
ULP  and  such  “half-named**  service  machines  are  distii^uished  by  local  con¬ 
nection  name.  A  fully-naaed  aervlce  machine  (if  it  exists)  will  be  connected 
to  a  remote  open  reqxiest  rather  than  a  half-named  service  machine  with  the 
same  source  port  and  source  address.  Then,  if  more  than  one  half-named 
service  machine  exists,  they  are  connected  to  matching  fully-named  remote 
open  requests  at  random. 

6.5.2  State  diagrams.  Because  of  the  split-state  model  presented,  both 
the  local  aervlce  uchine  state  diagram  and  the  composite  service  machine 
state  diagram  are  presented.  Figure  6  suoMrices  the  service  provided  by 
the  composite  TCP  service  aachine  as  derived  from  the  composition  of  emo 
local  service  machines.  The  boxes  represent  the  state  of  the  composite 
service  machine;  the  arrows  represent  state  transitions  resulting  from  the 
service  requests  and  service  responses  shoum.  The  *£X“  Labels  represent 
state  changes  resulting  from  the  periodic  exchanges  between  local  service 
machines.  This  diagram  serves  only  as  a  guide  and  does  not  supersede  the 
full  definition  of  the  composite  service  aachine  In  Section  6.5.  Abnormal 
connection  termination  states  are  enclosed  in  the  dotted  box.  These  states 
result  from  an  Abort  service  request  or  from  TCP  service  failure. 

6.5.2. 1  Service  state  machine  defined.  Figure  7  summarises  the  definition 
of  the  service  state  machine  for  the  local  service  aachine  appearing  in 
Paragraph  6.5.  This  diagram  presents  the  sequence  of  state  cha:^e&  from  the 
point  of  view  of  a  single  ULP  accessing  TCP's  services.  Th^  boxes  represent 
the  states  of  the  state  machine;  the  arrM  represent  state  trsMiclons 
resulting  from  the  service  requests  and  service  responses  shown.  Please 
note  that  the  diagram  is  intended  ovdy  as  s  summary  and  does  not  supersede 
the  formal  definition  of  Paragraph  b.5. 

6.5.3  State  vector.  The  service  machine  vector  of  a  local  service  machine 
consists  of  the  following  elements: 

s.  state  -  (aOSED,  AaiVE  OPEH.  PASSIVE  OPES, 
rcTAiLISMO,  CLOSIHG); 

b.  source  port  -  identifier  of  the  local  ULP. 

c.  source  address  (sv.  source^addr)  -  the  Internet  address  naming 
the  location  of  the  local  ULP. 


FIGURE  6.  Coayofly  TCP  a^rvlce  sftt  machine  dltgraa. 
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d*  dtitlnttlon  port  -  IdtntifUr  of  tho  remote  ULP. 

«•  dettiniitlon  address  -  internet  address  Identifying  the  location 
of  the  remote  ULP. 

f.  local  connection  name  -  the  shorthand  Identifier  used  In  all 
service  responses  and  service  requests  except  for  open  requests. 

g.  original  precedence  -  precedence  level  specified  by  the 
local  ULP  In  the  open  request. 

h.  actual  precedence  -  precedence  level  negotiated  at  connection 
opening  and  used  during  connection  llfetliM. 

1.  security  -  security  Infomatlon  (Including  security  level, 

coapartMnt,  handling  restrictions  and  trsnsalsslon  control  code) 
defined  by  tVie  local  UIP. 

1.  sec  rar«es  -  security  structure  which  specifies  the  allowed  ranges 
In  coapartwnt,  handUiqi  restrictions,  transmission  control  cudei 
and  security  levels. 

k.  ULP  timeout  -  the  longest  delay  .allowed  for  data  delivery  before 
automatic  connection  termination. 

l.  ULP  timeout  action  -  In  the  event  of  a  ULP  timeout,  determines 

if  the  connection  Is  terminated  or  an  error  Is  repoited  to  the  ULP. 

m.  open  mode  -  the  typt  of  open  request  Issued  by  the  local  ULP 
including  UNPASSlVg,  fULLPASSIVB,  and  ACTIVE. 

n.  seirf  qvmue  -  storage  location  of  data  sent  by  the  local  ULP 
before  transmission  to  the  remote  TCP.  Each  data  octet  Is 
stored  with  a  times tmap  Indicating  Its  time  of  entry. 

o.  send  queue  length  -  number  of  entries  In  the  send  queue  made  up 
of  data  and  tlmeatmap  Information. 

p.  send  push  -  an  offset  from  the  front  of  the  send  queue  indicating 
the  end  of  push  data. 

q.  send  urgent  -  an  offset  from  the  front  of  the  send  queue  Indicat¬ 
ing  the  end  of  urgent  data. 

r.  receive  queue  -  storage  location  of  data  received  from  the  remote 
TCP  before  delivery  to  the  local  ULP. 

g.  queue  length  —  nuirt>er  of  data  octets  in  the  receive 

queue. 

receive  push  —  an  offset  from  the  front  of  the  receive  queue 
indicating  the  end  of  push  data. 
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u,  receive  urgent  -  an  offset  from  the  front  of  the  receive  queue 
indicating  the  end  of  urgent  data. 

V.  receive  allocation  -  the  tsinber  of  data  octets  the  local  ULP  Is 
currently  willing  to  receive. 

Initial  state.  A  state  machine's  initial  statk*  is  CLOSED  with 
KULL  values  for  all  other  state  vector  elements. 

6. 5.3.2  Sec  range  structure.  The  structure  of  sec^ranges  is  largely 
implementation  dependent.  In  the  simplest  case,  it  could  be  implemented  as 
a  quartet.  For  example: 

(compartment) (hand ling  restriction) (transmission  control  code)(tec  level  range) 


In  a  more  coaplex  scenario,  the  implementation  could  be  tree  structured,  with 
the  number  of  branches  being  ((#  compartments)  x  (#  handling  restrictions)  x 
(^  transmission  control  codes)).  In  Figure  8,  each  branch  has  its  own 
aecurlty^level  range. 


eoMs  1 


TxaNtMisstom 
COMTSOl  COM 

•ICuetrv.Livii 

1 

Mmol 

raamsMtssiom 
comTnoi  cool 
•*1 


•icwaiTv^uvii 

RADlOC 


FICURE  8.  Coin  lex  sec  range  structure. 
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6.5.4  Data  atructurat.  For  clarity  In  the  events  and  actions  section,  data 
atructurea  art  daclared  for  the  Interaction  prlaltives  and  their  parameters, 

A  aubaat  of  ADA  data  const  met  a,  coafloi4  to  moat  high  level  languages,  la 
used.  However,  a  data  structure  may  be  partiaiv  typed  or  completely  untyped 
where  specific  formats  or  data  types  are  Implementation  dependent. 

6.5.4. 1  State  vector.  The  definition  of  the  TCP  service  machine  state 
vector  appears  In  paragraph  6.5.3.  The  service  machine  state  vectors  for 
the  two  local  TCP  service  machines  are  declared  as: 

svjl  :  state^vector^tTpe; 

svJS  :  state^vectorjtype; 

type  state^vector^type  is 
record  * 

- Hate  :  <  aOSBD,  ACTIVE  OPEN.  PASSIVE  OPEN, 

ESTABLISHED.  aOSING  ); 
sourcejiddr  :  sddrsM  type; 
source^of^  *  THOjOCIfTS; 
destlnatlonjiddr  T  sddress^type; 
destlnatlon3ort  :  TWOJOCTETS; 

Ico  :  Icn^type;  ” 

sec  :  securlty^type; 
see^rai^es  :  security  structure; 
orlflnal^rec  *  0..7; 
actual^rec  :  0..7; 

ULP  timeout  i  tims^typt; 

UIP** timeout  action  :  integer; 

open^mode  TCUNPASSIVE,  PULLPASSIVE,  ACTIVE); 

sendjiweue  :  tlmsdj^ueue^type; 

send^u^ue^ltngth  .*  Intsisr; 

send^u*^  :  integer; 

sendjurg  :  Integer; 

recvjqueu«_length  :  Integsr; 
reev^ush  :  integer; 
reev^urg  :  Integsr; 
recv*alloc  :  integer; 
end  record; 

timed  (|ueue  type  tjusue  (I..S1ZE_OF^SENO_EESOURCE)  of 
record 

lCTa_octet  ;  OCTET; 
tlmsTtamp  i  tims_type; 
end  record; 

type  -,usuc_type  Is  4»*ue  (U.SlEEjOr^IECVJlESOURCB)  of 
da?a_octet  :  OCTET; 
end  record; 
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type  eddrcss^type  is  FOURJOCTETS; 

type  lenity pe  :  undefine'd;  — l»ple«entttlon  dependent 
type  securlty^struct  :  undefined;  — iupleaentstlon  dependent 
type  tiae^type  :  undefined;  — lupleaentttlon  dependent 

subtype  OCTET  Is  INTEGER  range  0..2S5; 
subtype  TWO  OCTETS  Is  INTEGER  range  0..2**16-1 
subtype  FOURJOCTETS  Is  INTEGER  range  0. .2**32-!; 

6.5.4.2  Froa  ULP.  The  froUjULP  structure  holds  the  Interface  parsaaters 
and  data  associated  vlth  the  sVivlce  request  prlaltlves  specified  in  Section 
3.I.I.  Although  the  structure  is  coaposed  of  the  paraasters  froa  all  the 
service  requests,  a  particular  service  response  will  use  only  those  structure 
elenents  corrasponding  to  its  specified  paraasters.  This  structure  directly 
corresponds  to  the  froaJULP  structure  declared  in  entity  state  aachine  speci¬ 
fication,  paragraph  9.474.2.  The  froaJILP  structure  is  declared  as: 

type  froaJULPjtype  Xm 
record  " 

requestjOsae  :  (UnspecifiedJPassiveJOpen,  Full  FsssiveJ)pen, 
ActivijOpenT  Actlvt3>P*njiflthJ3ats,  "" 

Send,  Allocate,  Close,  Abort ,*$10100); 

sourcejSddr 

source^o^c 

destinationjSddr 

destlnation^ort 

len 

t  las  out 

precedence 

security 

seCjianges 

dat7 

datSjlength 
pushTflag 
urge  ntjf  lag 
end  recoTd; 

6. 5.4.3  To  ULF.  The  toJULP  structure  holds  interface  paraasters  and  data 
associated  ulth  the  service  response  priaitives,  as  specified  in  Section 
4.4. 10.  Although  the  structure  is  coaposed  of  the  paraasters  froa  all  the 
service  requests,  a  particular  service  response  vill  use  only  chose  structure 
eleaencs  corresponding  to  its  specified  osraaeters.  This  structure  directly 
corresponds  to  the  coJULF  structure  declared  in  paragraph  9. 4. 4.3  of  the 
atchaniss  specification.  The  toJULF  structure  is  declared  as: 

type  toJULFjtype  is 
record  “ 

servicSjresponae  :  (OpeOjId,  OpenJFsil,  OpenjSuccess, 

Deli^ar,  StatuTjResponse,'*terainate. 

Error);  " 

aoureSjaddr 
sour  escort 
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dMCination^addr 

dtttlnatlonjport 

Icn 

data 

data^Ungth 

urgtat^flag 

trrorjitac 

•  tatuT^bloek  i  atatui^block^typt; 

tnd  ytcoTds 


typt  ftatuf^block^typt  li 
racord  *  "" 

coaMct  ioaji  tatt 
aaadjvlndoir 
rtcaTvtjrlndov 
aaouatjof^uaaekad^dat  a 
aaounCjtfj^nrtcalvadjdata 
urfiat^tcTta 
prtctdTnea 
aaeurltj 
•aejraiiftf 

tlMOutjictlon 

tad  ttcordT 

6.5.5  lytat  Hit.  Tbt  fttati  for  tht  TCF  atrviet  ■adilat  art  drum  fro* 
tbt  atrviet  rtqutat  pri«ltivta  dtfintd  la  Stetioa  6.3.  Optioaal  ttrvict 
rtqatat  ptrtMCtn  art  ahova  la  braebttt.  Tbt  eipitalittd  Uat  of  paraatttra 
rtprtttac  tbt  actual  valuta  of  tbt  paraatttrt  paattd  by  tbt  ttrvict  priaitivt. 
Tbt  tvtat  Uat) 


a. 


Oaaptcifitd  Faaaivt  Opta  (SOURCS  FOFT. 

UTXICBuTI  MXHEOUT  ACTIWl 
[.FRICEDRRCRI  ( .SCCJUHCES ) ) ; 


b.  Full  Faaaivt  Opto  (SOURCE  FORT, 

DESTINATION  FORT,  OCSHNATIOH  ADDRESS, 
l,Tl«OUT|  T,TX«0UT  ACnORl  T.FRECEDCNa) 
USBC  RANGES]): 


c.  Activt  Opto  (soma  FORT, 

OESTXt^TION  FORT,  DESTINATION  ADDRESS 
C,TI«OUT|  T.TIJCOUT  ACnON]  T.FRECEDENal 
t,S8CURXTTl); 


d. 


Activt  Opta  u/data  (SOURCE  mT, 

DESTXiffTXON  FORT,  DCSHNATiOH  ADDRESS 

!,TX«ouTl  Tjiicout  action]  T.friceochcei 

t, SECURITY)};  DATA,  OATAJ.EICTH.  FWH^FUC, 
URGENT  FUG); 
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e.  Stnd  (LCN*  DATA,  DATA  LENGTH,  PUSH  FLAG,  URGENT  FUG  l,TIMEOUTl 
I  ,Tltt0UT_ACT10NT)  I 

£.  Ailocstt  (LCN,  DATA  LEHCTH) 

Clofit  («.CN) 

h.  Abort  (LCN) 

I.  Stiitus  (LCN) 

J.  NULL  -  Although  no  strvice  roquott  It  itsutd  by  •  UI^,  etrtsln 

conditions  vlthin  tho  TCP  strvlct  Mchlnt  product  a  strvict 
rtsponst. 

A ,5.6  Evtnts  and  tctions*  For  tht  purposts  of  this  dtflnltlon,  tht  ULP  and 
TCP  antitias  art  idtntlfitd  with  tht  capital  lattars  "A*  and  "B."  Tha  first 
UIP  to  naka  a  sarvica  roquatt  is  laballad  Ul^  "A";  its  local  sarvica  aachina 
is  TCP  "A.“  Tha  paar  ULP  and  its  TCP  ara  laballad  ULP  B  and  TCP  B.  Tha  aarvica 
roquasts  ara  laballad  with  tha  idantifiat  of  tha  issuing  ULP,  such  as  Closa/A. 
Tha  sarvica  rasponsas  ara  siailarly  laballad,  such  as  Taniiiiata/B.  A  sarvica 
raquast  i^paarii^  with  a  ****  Idantifiar  say  ba  Issuad  by  altbar  ULP  A  or  ULP 
B.  Tha  appropriata  TCP  handlas  tha  roquast  updating  its  own  stata  vaetor  If 
nacassary.  Tha  sarvica  rasponsv*  corras^ndlng  to  sveh  a  roquast  is  dlractad 
to  tha  appropriata  ULP.  Whan  a  sarvica  roquast  is  invalid  for  tha  currant 
stata  of  tha  stata  luchlna,  tha  sarvica  roquast  appears  without  a  paraoatar 
list.  In  this  sarvica  oadhina  oodal,  ^sioultanoous*  oorvieos  ora  traatad  as 
unordarod  saqutntial  ovants.  Hanoa,  aoSE/A  occurring  "sioultanaously*  with 
CLOSE/B  is  raprasantad  as  occurring  soquentiaXly  without  intarvaning  avants. 

Tha  ordar  chosan  for  tha  avant  saquanca  should  not  sltar  tha  resulting  stata, 
so  that  a  saquanca  such  as  (CLOSE/A,  CLOSE/B)  should  load  to  tha  sous  stata 
as  tha  (CLOSE/B,  aoSE/A)  saquanca.  Tha  STATUS  avant  producas  tha  saoa 
sarvica  rasponsa  iron  tha  TCP  sarvica  oschina  in  avsry  stata.  Rathf^r  than 
s)»w  thasa  in  aach  stata,  tha  STATUS  roquast  and  STATUS  KESPONSE  rasponsa 
ara  shown  ones  hara. 

Event:  STATUS  (LCN) 

Actions:  STATUS  RESPONSE  (LCN,  SOURCE  WRT,  SOURCE  ADDRESS, 

DESTINATION  ?6rT,  DESTINATION  ADDRESS, 

PREaOCMCE, "SECURITY,  CONNECTToN^STATE, 

RECEIVE  WINDOW,  SEND  WINDOW, 

AHOUNT  WAITINC  ACR,  AMOUNT  WAlTlIICJtEaiPT, 
URCENTJR)DC,  tTiCOUT,  niCOUT^ACnON); 

6.5.6. 1  Evant/actlons  snaclflcations.  Tha  following  saetion  is  organlsad 
by  cooposite  state.  Nlrror*ioap  cooposita  statas,  auch  os  PASSIVE/ACTIVE 
and  ACriVC/PASSIVE,  appanr  os  Just  ono.  Only  onr-way  data  transfar  is  raprt- 
stntad  by  tha  sarvica  oschina  slnca  tha  data  transfar  sarvica  is  syooatric. 
Thus,  a  definition  of  bi*diractional  data  transfar  can  be  providad  by  dupli* 
eating  tha  aidsting  ona*way  daflnition.  Certain  conditions,  checks .  and 
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groups  of  actioos  occur  In  atvtral  placas  and  hava  baan  foriMd  Into  daclalon 
fimctlov  awl  action  proctdurts.  Tht  daclslona  function  dafinltiona  appear 
in  paragraph  6,5. 6,2,  The  action  procadura  dafinltiona  appear  in  paragraph 
6.5.6.3. 

6.5.6.1.1  State  A  ■  cloaad,  atata  i  ■  cloaad. 

Event:  Unapaclfiad  Passive  Opan/A  (SOURCE  PORT  (,TIHB0UT|  I .TlfCOUT^ACTlON 1 

(.PRECEDENCE]  (.SECJtANGES) ) 


j  Actions: 


racord^opan^^raeatan  (A,  UNPASS XVE); 
av  A.len  :■  assign^^naif^lcn; 

open  id  (tv  A.lcn,“ay^a.aottrca_^rt,  av^A.aourca^addr, 
TRANIrr  to“ULP  to  thit  ULP  naead  by  av^A.aourcaj^ort; 
svjl* state  T»  PASSIVE^OPEN; 


NULL,  NUU); 


Event: 


Full  Passive  Open/A  (SOURCE^^PORT, 

DESTINATION  PORT. 
(.Tl«OUTJ®nON| 


DESTINATION  ADDRESS  (,Tl«0UTl 
l.PUCEOENCll  (.SECJUNCaSSl) 


Actions:  record^opeo^^^raesters  (A.  FOLLPASSIVE) ; 
sv  A*icn  :•  asaignjiser  Icn; 

oMn  idC  sv  A.lcn,  sv  A.source_port,  sv^A.sourca^addr, 

•  ~  sv"A*dsstiiiatlonj»on,  sv^A.dsstination^addr); 

TRAHSRR  to  ULP  to  the  ULP  nsMd  by  sv^A.eource^rt; 
sv  A. state  7-  PASSIVEJDPEN; 


Event: 


Active  Opan/A  (SOURCE  PORT,  OESTINAHON^PORT.  DESTINATION  ADDRESS 

(.Tl«cifrj  (.TIHEOUT  ACTION)  (,  PRECEDENCE  I  LSEC^RANCESl) 


Actions:  racord^opao^paraestars  (A,  ACTIVE); 
sv  A.ien  :•  assign  nev^lcn; 

OMO  U(  sv  A-lcnTiv  A.aourcajport,  sv^A.aourea^addr, 

“  •  ivj^.dsstination ^rt,  sy^A.dsstinatlon^addr); 

TTANSRR  tojnj  to  this  ULP  naead  by  sv^A.aourca^rt; 
sv  A* state  7»  ACTIVE  OPEN; 


Event: 


Active  Open  ulth  data/A  (SOWCE  PORT, 

destination  port.  DESTINATION  address 
(,TII«OUT]  T*TI>C<HJT  ACnONj  T*PREaOENCEj 
(.SEC  RANCESJ  DATA,  EaTAJJINCTH,  PUSM^FLAC, 
URGEilT  FLAG) 


Actions:  sv  A,lcn  :•  aaalgRjnev^lcn; 

mn  id(  sv  A.lcn,  sv  A.sourca^rt,  av^A.source^addr, 

"  "  svJU  dee t Inst  ion^rt,  sv^A.daatlnation^addr); 

TRANSFER  to  ULP  to  ths*UlP  narsad  by  av^A.sourca^rt; 
if  (  rooe^loTs v^A.  aandjtuaus ) 
thsn  ~ 


vv 
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•dd_t  ojitodj^utut  ( tvjl) ; 
rteord** n  (A,  ACTIVE) ; 

•vJlstTstt  :•  ACriVEJOESM; 
tlM  ** 

opsofall  (tv  A.ien); 

TEANSFBE  to  tht  ULE  ttiMd  bgr  tx;  A^toureo^^rt; 


Evontt  Clott/A  (LOt) 

or  Abort/A  (LCN) 

or  Alloestt/A  (tCN.  DATAJJBNGTH)  $ 

Aetioao:  trror  (ov^A^lea,  *CocifitetioD  dooo  not  tidtt**): 

TEANSFEE  ToJJlP  to  tilt  ULP  MMd  hf  tvjl.oourco^rt; 

8.5.6«1«2  If  tt  A  «■  pottivt  optp.  sUf  i  •  clotod* 

Evont:  Clott/A  (LCN) 

or  Abort M  (LQt) 

Act  loot:  initialiit  (tvjDi 

•V  A*ttttt  t*  a«0$ED| 


Event  I  Uotpteiatd  Ptttivt  Opeo/1  (lOUlCE  fOET  C,Tt«0aT)  UtXICOUT  ACTION) 

l.ruAKNCEl  (.nCJURGESl) 

Aetioot:  tv^i.lea  ;•  Mtlgnjotv^lens 

record  open  MitMteit^d.  OWASIIVE); 

open  l7  (tv  l.lcn,  tv  B«oource^^rt»  exr  i.eouree  eddr»  N0LL»  NOLL); 
nAMSrcil  toHlir  to  tl«  UU  aM04  bgr  rr  f.ooureo  p»n; 
o«  S.ototo  T«  rASSKC  OKNi 


(«toti  Foil  Foooivo  Opoa/I  (MOta  FOtT, 

DitnifTnoM  FOtT,  ottniitTioti  Arateu 
f.TlICOUTl  T.T1«00T  ACnOH)  T.FUaiEIKel 
I.SKJMICBtl) 

Ac: lent:  ev^iolcn  :•  eetifBjnei^lctt: 

reTord  open ^ereMTeie**(B,  POLUASUVS); 

open^i?  (tv^iolca,  oe^iotoiiree^^rt,  evjloeeurce^eddr, 

*  *  evJI*dttttnetton^it,  ovjl.fetlnetionjiddr); 

TEANSfEE  to  OLF  to  tlie  ULF  meed  bp  tv  iotome^rt;  ** 

•V  Bottete  T*  PASSIVE  OPEN; 


Event:  Active  Open/B  (SOOECE  POET.  OCSTlNAnON  P0Et«  OESniAnON  ADOEESI 
|,Tl«OOr)“UTXI«OOT  ACriON)’’|.PEEaXNCE)  uslcuim)) 
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Actloot:  r«cor4_opto^r«attcn  (■•  ACTIVE); 

•v^l.ien  2"  aaelfiijBCtf^len: 

opctt  14  (tv  l.lco,"ivjr.tourct^rt,  Avjl.iourct^addr, 

“  tVY.dtAtination^ort,  tifwtlonjiddr); 

TRANSIEI  toJJlP  to  tht  tJLF  noMd  by  tvJl.iOiJct^rt;  " 
•v^B.otott  2*  ACTIVEjlFEN; 

Ewat:  Actlvt  Opto  irlch  4ata/B  (SOUtCE^WtT, 

DESTIMATXON  PORT,  MSHHATIOM  ADDRESS 
I.Ti«oOTl  T.ti*out  Acnom  T.nacEBeKOi 
(,sEct*mi  DATA,  oaTajxmctm,  ro$H_ruc. 
OIOMT^PLAC  ~ 

Aetloo«:  tv^B.lca  :•  Mi  Ifajatw^lea; 

4iin  14  (iv  B«len7  ivjl.ioyrcij^rt,  tvjl.iourcijiddr, 

"  *“  tV" l.diitlMtlon^rt,  iiJI.4tttl«itlon^i44r); 

TRAMSnt  to  DIP  to  tht^DlP  namd  by  •vJ.iO«rct^n: 
if  ( rooa^lnTiv^l*  Modjqotui ) 
thin  "  * 

iddjto^iindjtutui 

roe^rd*” opio^iriattirt  (B,  ACTIVE); 
iv^B.otiti  :•  ACTIVEjaPEII; 

ilM 

opinfill  (ii  B.lcfi); 

TRARSFER  toJTlP  to  thi  OT#  oiMid  by  iv^B.Mttrci^^rt; 

Evint2  AUoe*ti/A  (tCN,  DATA^LBRCTII) 

Aetlont:  tvj^*  ricv^tlloc  2»  iv^A«  ricvjtllot  ♦  DATAJLERCTM; 


Ewtnt:  Pull  PMfiui  Opon/A  (  ) 
or  Sind/A  (  ) 

AetloM:  irror  <iv  A.len,  *llli8il  roquitt**); 

TRANSPER  To^ULP  to  thi  OIP  n««id  by  iv^A.iourci^rt ; 


BviOt2  Cloii/B  (  ) 

or  Abert/B  (  ) 
or  Stnd/B  (  ) 
or  Allociti/B  (  ) 

Actions;  irror  (tv  B.lcn,  miigil  rnquitt.*): 

TRARSIER  7oJ»lP  to  thi  ULP  noaid  by  ivjl.iwei^ri; 


‘.s 
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6.5.6.1.3  Ststt  A  ■  setlv*  optn.  ststt  B  •  clottd. 


Event:  Clost/A  (LCN) 

or  Abcrt/A  (LCN) 

Actions:  initislist  (sv  A); 

sv  A* s tits  :■  BOOSED; 


Event:  Allocete/A  (LCN,  BATA^LENCTB) 

Actiofu:  svjl*recv_slloc  :•  sv^A.recvjslloc  ♦  OATAJLENCJTH; 


Event:  Send/A  (LCN,  DATA,  DATA  LENGTH,  PUSH  PLAC.  UICENT  FLAG 

l.TiMEouTj  t,nHt«rrjieTioti57 

Actions;  it  (core  in(sv  A.scnd  queue)) 

th(o  if  iTtwoKFr  /-  rifu) 

then  svJl.ulp^tiasoMt  :•  TIHEOVT; 

•dd^tojsend  queue  (sv  A); 
else  error(Tv^A*Tcn»  '‘InsuTflcient  resources**); 

tlUNSFElTtoJILF  to  the  ULP  neaed  by  svjt.eouree _^rt; 

Vmnt:  Unspecified  Pessive  Open/B  (BOUNCE  PONT  |,TXMiOUT|  l•TllCOG^  ACHONi 

l.nticfoeiice)  i.stcjumoesi) 

Actions:  sv^B»lcn  :•  essi^_ne«^lcn: 

re?ord  open^erseeTenTCB,  IMPASSIVE); 

open^i?  (sv^B.lcn,  sv^B.source^^rt,  svjl.soutce^eddf ,  NULL,  NULL); 
TIANTpEB  to*ULP  to  the  ULP  eeaed  by  ev  B«souree^rt; 
sv  B.stste  T«  PASSIVE  OPEN; 


Event:  Puli  Pessive  Optn/B  (SOUBCE  PORT, 

DESniKTlON  PORT,  DCSnmTlON  ADORERS 
(,TllftOUT|  T.TltCOCT  ACnONi  T.PRSCEOENai 
|,SECJUVIGES)) 

Actions:  sv  B*lcn  :•  sssi^s  nev^lcn; 

rsTord  open^rseeTecs**(B,  PUU/ASSXVE); 

open^i?  (svji.lcn,  sv^B*source^^rc,  sv^B.source^eddr, 

*  sv*B«diStiiistion^^n,  sv^B,£stinetionjsddr); 

TRANSFER  coJSLP  to  tbs  ULP  neeed  by  ev^B.soifce^rt;  ** 
sv  B.stste  T»  PASSIVE  OPEN;  * 


Event:  Active  Open/B  (SOURCE  PORT, 

DESTltiTTION  PORT.  DESTINATION  ADDRESS 

t,TllCOVT!  T,TIIC0UT  ACTION)  T, PRECEDENCE)  {.SECURITY)) 
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Act loos: 


svJl.lcQ  :•  ssslfo^now.lcn; 

rMotd  opto  PS rsBs tors  (8*  ACTIVE); 

opiB  t7  •»Jl.toore#_pon.  .»_».toure«  •ddt, 

sv^l •dost lost loo^rt»  svJI*dtstliistlon_sddr), 
TIAMSFEK  to  OIP  to  tht  ULP  nsood  by  st_l-soutct^rt; 
svji.otstt  T-  AcrxvEjarEM; 


Eusot:  Active  Opto  »#lth  dsts/i  (SOWCE^POIT, 

DESTINATION  POET,  DESTINATION  ABDEESS 
[,TII«OOT|  T,T1«0UT  ACTION!  T.fEECEOENCEl 
(,SECUEXTTl  DATA,  DA?AJX)^3TN,  FUSM^PLAC, 
UECENT  PLAC) 


Actloos:  sv  l.len  :•  ssslgojitt  Ico; 

opto  14  (st  l.lco,  svjl.sottrct^rt,  stJl.sourct_s44f , 

—  “  8,4tstlostloo^rt,  sv^E*4tstlnstloo^s44r); 

TEANSPEE  to  CLP  to  tht  OIF  os«t4  by  sv^E.sourct^rt; 

IT  (coo«^loTst^E.itodj|uti«) 

thso  td4jto_sto4j|usut  (svjl); 

rtcord*opto  Mttosttrt  (E»  ACTIVE); 
svj.ststt  :•  ACTIVEJDFEN; 

tlst  optnftll  (tv  lalco); 

TEANSPEE  to  OIF  to  tht  OIF  osMd  by  svJ.sourctjpon; 


Euiot:  Pull  Ftssiui  Opto/A  (  ) 
or  Act  lot  Opto/A  (  ) 
or  Actlut  Opto  ifith  4stt/A  (  ) 

Actloos:  trror  (tv  A*lcii,  *tllt|tl  rttuost.*); 

TEANSPEE  to  OIF  to  tht  OLF  osasd  by  st^A.  sourct^ri : 


Eutot:  Sto4/l  (  ) 

or  Cltst/I  (  ) 
or  Abort/I  (  ) 

Actloos:  trror(sv  l.lco,  *lllt|sl  rtgutst.*); 

TtANSPEE*to  OIF  to  tht  OIF  osMd  by  su^E.sourct^rt ; 


Evtot:  ISOU* 

Actloos:  lottrosl  Evtots 

1)  If  tltsout  tscttdtd 

thto  If  (0l>  TINEOOT  ACTION  •  1) 
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thtn  opeofaU  (tv  A.  lew); 

Transfer  to  to  cht  UU*  Boaod  by  tv  A^oourct  oort; 
imtlollff  Tiv  A);  •  -r  • 

•vjl.itfttt  t«  Q^ED; 

tlM 

tEFORTjrilCOUT  (tv  A); 

8.5.6.1.8  Stitt  A  •  poitivt  optn.  if to  I  •  octlvo  opon. 

Evtfit:  Clott/*aCN) 

or  Abort /•(LOI) 

Aetiooi:  iiltlilltt  (it  •); 

•v^*,ttitt  j-  Closed; 


Ettot:  Allocitt/*aCII,  OATAJLENCTS) 

Aetlout:  iv^A.rtc/^illoc  !•  iv_*.r«ev_illoc  ♦  DA?A^lS5f(JT«; 

Ettnt:  Stnd/I  (LO*.  DATA.  DATA  USCTS.  FUSE  fUC,  DRCENT  FUC 

l.tiwovT)  (.TiTkooTAcnoErr 


Act loot} 


il  (ro«i  ia(iv  l.itfitf  outlie) 
thti 


oXit 


If  TrilfcoUT  /•  WLD* 

thtn  ivJl^itlp^tSatouC  i*  tlMEOUT; 


error  (i«JI«lea.  latuffuiort  rwioorcM**); 

TRAESfCt  toJU-F  to  tho  DIF  lunod  by  ivjl^ooorco^rt 


Etoot:  Sofid/A  (  ) 

Act  loot:  error  (ev^A.lco.  llUfil  renoeet-*); 

TSAESns  ioJ?lF  to  tbt  DIF  aioed  by  ovJU  eoorce^rt ; 


Evtmt  Foil  Fiittve  Ooen/«(  ) 
or  Actt^yta/*{  ) 
or  ActlooOyeo  vttb  4iti/*(  ) 

Aetloee:  error  (o*_Mco,  -UJofil  r«|ooet.*); 

TtAKSFtt  to^DlF  to  tbt  Dt/  aeat^  by  ov^o.eoorce^^rt; 
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Evcat:  NULL 

Act  loos:  IntenuLl  Evtuts 

1)  If  not  SECJIANCEJIATCH  (svjl); 
thtn  ""  ""  ” 

openfsll  (tvJB.lcn); 

TRANSFER  to_ULP  to  ths  ULP  naatd  by  tv  B«sourct  port: 

Inltlalls*  (ty^B); 

•y_B»ttatt  :■  ^OSED; 

tl«s  — T«k#  grtattr  pracadanca  laval  to  aodal  pracadanca  nagotlatlon; 
-^If  nagotlatlon  la  not  aupportad,  nlsaatchad  pracadanca 
**-ls  handlad  tha  Sana  as  alsaatchad  sacurlty. 

If  (ftv^A.origlnal^^ft':  /•  av  B.  original  prac) 
than  "" 

•Y_A*actual^rac  naxlaua  (ayjl.orlglnal^rae, 

av  Btorlglnaljprac); 
avjl.actuiajprac  aaxlaua  (svJUorlglnal^prac, 

a vll  • orlgl nal  prac ) i 

If  (ayjA,opan_aoda  -  OHPASSIVE) 
than 

syjk.dastlnatlonjiddr  :■  sv_B»aourcajaddr; 
•y^A«daatlnatlon_^rt  *•  av^vtourcajM^t; 
load  aacurlty  (tv  A);  ~ 

•yjTttata  ESTABLISHED; 
op7n_auecatt  (avjk.lcn); 

TRANSFER  toJDLP  to  tha  ULP  naaad  by  tv  Antourca  port; 
av^B.atata  *-  ESTABLISHED; 
opan  auccaaa  (av^B.len); 

TRANSFER  to^ULP  to  tha  ULP  naiMd  by  av  B«aourea  port; 

If  tloaout  axcaadad  (av  B);  * 

than  If  :uT>jriHEOUTjlCriON  •  1) 


OR. 

2)  If  tlaaout_axcaadad(av_B) 
than  "" 

op*nfall  (svJB.lcn); 

TRANSFER  to  Ul^  to  tha  O.’F  naaad  by  av  B«len; 
Inltlallaa  Tav  B>;  “ 

av  B.atata  :•  &OSED; 

alsa 

REPORT^TXMEOUT  (av_B); 

6«5«6«1«5  State  A  •  ^aaalva  opan.  atata  B  •  paaalva  opan> 
Event:  Allocata/*(LCN,  DATA^LENGTH) 

Actlona:  av__*, racv^alioc  :•  av_*.racv  alloc  DATA  LENGTH; 
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Evtnt:  Clotc/*(LCN) 

or  Abort /•(LCN) 

Actions:  Inltlsllst  (sv_*); 

sv  *«stste  :■  CLOSED; 


Event:  Full  Pssslve  Opcn/*(  ) 
or  ActlvtOptn/*(  ) 
or  ActivtOptn  with  dsts/*(  ) 
or  Stnd/*(  ) 

Actions:  #rror(sv  ♦•Icn,  *IlUfsl  request. *); 

TRANSFERTtoJULP  to  the  OLP  nseod  by  sv_*.  sour  comport; 

6.5.6. 1.6  Stttt  A  »  setivt  ortn.  ststs  B  ■  active  open. 

Event:  Allocste/*(  LCN,  OATA^UNGTH  ) 

Actions:  sv  *.recv  slloc  :■  sv^*.recv^«lloc  ♦  DATA^LEHCTH; 


Event:  Close/*(  LCN  ) 

or  Abort /*(  LCN  ) 

Actions:  inititliteC  sv^*  ); 

sv  *•  state  :•  CLOSS); 


Event:  Full  Passive  Open/*(  ) 
cr  Active  Open/*<  ) 
or  Active  Open  with  data/*(  ) 

Actions:  errorCsv  *.lcn,  "Illegal  request.**); 

TRANSFER^to  ULP  to  the  ULP  naeed  by  sv^*.sourcsj>ort; 


Evtnt:  Send/*(  LCN,  DATA,  DATA  UNCTH,  PUSH  FUC,  URCENT^FLAC 
I.TIMCOUTl  I.TllCOUT_ACnONjT 

Action:  if  (rooB_in(sv_^.seiidjqusue) 
then  "" 

add  to  send  queue (sv^*); 

if  Triftour"/-  null) 

then  sv_*.ulp^ti«sout  :•  TXttOUT; 

else 

errorC  sv  *.lcn,  "Insufficient  resources."); 

TRANSFER  To  ULP  to  the  ULP  naeed  by  sv^’^.sourcejwrt; 


MILITARY  STANDARDS:  TCP 


MIL-STD  1778 


MIL-STD-1778 
12  August  1983 


Evtnt  NULL 

Actloni»:  Internal  Evtnt s 

1)  If  (sv^A.ttc  /-  svJB.stc) 
thtn 

openftlK  sv^A.len  ); 

Trim  ft r  toJfLP  to  tht  ULP  ntatd  by  tvjl*  tourct^ort ; 
optnftlK  svjl.lcn  );  “ 

Trtntftr  toJULP  to  tht  ULP  naatd  by  tv  B«tourct^ort; 
inltltllst(  iv_A  );  sv^A.ttttt  i-“CL0SED; 

InltltliitC  sv“b  );  svjl^itttt  :•  CLOSED; 

tlit  — ttkt  grttttr  prtctdtnet  Itvtl  to  aodtl  prtctdtnct  ntgotlttlon; 
-”if  ntgotlttlon  not  support td,  aisiBttchtd  prtctdtnct 
**l8  htndltd  just  ts  BlsMtchtd  stcurlty 
If  (sv^A.orlglntl^rtc  /•  svjl.orlglntl^rtc) 
thtn  “ 

•v_A*tctutl ^rtc  :•  MxlisuaCiv^A^origlntl  prtc» 

s^B.orlglntl^rtc) ; 

svjl.tctutljprcc  :■  stxlau«<sv_^orlglntl^rtc, 

iv" l.orlglntl  prtc); 

sv^A.stttt  i-  ESTABLISHED; 
svJ|*otttt  t-  ESTABLISHED; 
op«n_succt8s(  sy^Atlcn  ); 

TRANSFER  toJJLP  To  tht  DIP  otMd  by  tvji.  tour  cohort; 
opttt_fuccttt(  tv^Btlcn  ); 

TRANSFER  to  ULP  to  tht  ULP  otatd  by  sv_B*sourct^ort; 

If  tlatout^txcttdtd  “ 

thtn  If  (ULP  tlatout  tcTlon  ■  1) 


OB, 

2)  thtn  optnftlK  sv  A.len  ); 

TRANSFER  tojilip  to  tht  UIP  ntmd  by  sv  A. sour ct  tort; 
InltltUstuvJl);  * 

av^A.stttt  :•** CLOSED; 


OR, 

3)  If  tlMOut  txcttdtd  (svjl) 

thtn  If  (urp_^tliigout_t€Tlon  •  1) 
then  "  “ 

optnftll  (sv  B.lcn): 

TRANSFER  to  HlP  to  tht  ULP  noMd  by  sv  B. source  port; 
Inltltllcc  Ttv_B);  "" 

svjl.stttt  :•  ^OSED: 
else  "" 

rtport^thr'4tt; 

8.5.8,1«7  Stttt  A  *  tsttblishtd,  stttt  B  •  osttbllshtd* 

Event:  S«nd/*(  tCN.  DATA,  DATA  LENGTH,  PUSH  FLAG,  URGENT  FLAG 
i. TIMEOUT)  |,Tl?fe0UT_ACri0NjT 
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Action:  If  (rooB_in(iy_*.itndjiutue) 
add  To  send  queue(sv_*); 

if  Ttikiout”/-  hull) 

then  sv^**ulp^tl«BOut  s*  TIICOUT; 

else 

errorC  sv  ‘.Icn,  Insufficient  resources.  ); 

TRANSFER  To  ULP  to  the  ULP  naaed  by  sy^*.  sour  carport; 


Event:  Allocate/*(  LCN,  OATAJZNCTH  )i 

Actions!  6V_*.recv_alloc  !-  sv_*.recv_alloc  DATAJJWCTH; 
lf*"(iy__*.Tecvjqueue^ltngth  >0) 

then  tTy^to^dtllverT 


Event:  Abort /*(  LCN  ) 

Actiom:  teniinate(sv_*.lcn,  “User  abort. “); 

TRANSFER  to  ULP  to  the  ULP  naaed  by  sv_*.source^rt; 

initial! sersv*  ); 

sv  *. state  !■  ttOSED; 


Event:  Close /*(  LCN  ) 

Aetiem:  :•  .v  *.$.i>d_q..u._l.ntth| 

sv**^ *. state  !■  CLOSINu; 


Event: 


Full  Passive  Opsn/^'C  ) 
or  Actl^  0pen/*(  ) 
or  Active  Open  vlth  dsta/*(  ) 


Actions:  errorCsv  •.!€«,  “Illegal  request."); 

TRANSFER  toJJLP  to  the  UIP  naaed  by  svj.source^rt, 


Event:  NULL 


Actiow:  Internal  Events 


—for  cUrity,  one-usy  date  transport,  froa  TCP  A  to  TCP  • 

—because  the  date  transport  service  is  syaaetric,  the  follomng 
—text  could  be  duplicated  to  represent  bi-directional  data  transport 


1)  if  tiaiout  exceeded(svjR) 

then  if  (ULP^tiaeou traction  •  1) 
then 

t»ralnate(sv  A.lcn,  W  tiaeout.  ); 

TRANSFER  toJuLP  to  the  ULP  naaed  ly  sv^A.source^portj 

initialiteCsvJ^); 

av  A.stsie  :•  CLOSED; 
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tlse 

report  tlaeout; 


OR, 

2)  if  (conditions  exist  such  that  no  data  can  be  exchanged 
by  local  state  machines  ) 

then 

ter0inate(8y_A,lcn,  "Service  failure."); 

TRANSFER  toJJLP  to  the  OLP  named  by  sv  A.  sour  carport; 
tfiminatsCsT^B.lcn,  "Service  failure. "T;  * 

TRANSFER  toJjLP  to  the  UIP  named  by  svjl. source j)ort; 
initialise(Tv_A);  sy_A. state  :•  CLOSEdT 
initialise (sv~B):  sv^.state  :•  CLOSED; 


OR, 

3)  if  (the  data  exchange  between  local  state  machines  is  triggered) 
then 

if  (ay_A.aendj;irg  /•  0) 
then  “  " 

sv^B.recvjurg  *•  (ay^B.recvjquaue^length  ♦  sv^A.sendjtrg); 

Dequeue  somt  portion  of  data  equal  to  "amount" 

(amount  may  be  >•  0)  from  sv^A.sendjqueue 
and  append  to  sv^B.  recvjqueue; 

if  (amount  >0) 
then 

svjl.sendjtuaue^length  av^A.sendj^uftue^length  -  amount; 
sv*B.  recv^queue^length  :•  svJI.recvjqueue^length  ♦  amount; 

if  (svjk.sendjjrg  •<  amount) 

then  svjk.se ndjurg  0; 

else  svjAtSendjirg  t*  sv^A.sendjtrg  *  amount; 

if  (svjk.send^ush  •<  amount) 

then  s7^B.rscv_^ush  ?•  svjl.recv^ush  ♦  sv^A.send j»ush; 

av^A.seni'^sh  :•  0;~  "" 

else  svjk.sei>d_push  :•  svjk.send^ush  •  amount; 
try^to^de  liver;  " 

8.5.6. 1.8  State  A  •  established,  state  B  •  cloalng. 

Event:  Send/A(  LCN,  DATA,  DATA  IZNCTH,  PUSH  FLAG,  URGENT  FLAG 
I.TIHEOUTI  t.TlttOUTjkaiONlT 

Actions:  if  (room_in(sv^A.send  queue) 
add  To  send  queueTsv  A); 
if  Tti«out“/»  NULL)“ 
then  svjk.ulpjtimeout  :■  TXICOUT; 

else  " 

error(  svjk. Icn,  "Xnsuf ftcient  resources.*); 

TRANSFER  ToJi)LF  to  the  ULP  named  by  svjk.  sour  carport ; 
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Evtnt:  Close /A(  LCN  ) 

Actions:  sv_A« send^push  :•  svJl.stndjQueue^lengthi 
•v"" A.stste  :■  CLOSING;  ""  "" 


Event:  Allocs tt/*(  LCN,  DATA_LENGTH  ); 

Actions:  sv_*.rtcy_slloc  :•  sv_*«recv^slloc  ♦  DATA^LENGTH; 
if” (sv_*.7ecyjqusut_ltnith  >"0) 
then  try_to  dTllverT 


Evtnt:  Abort /*(  LCN  ) 

Actions:  initisllttC  sy_*  ); 

sv_*.ststt  :•  a«OSCD; 
terelntte(sv_*,lcn,  *TJstr  short* **); 

TRANSFER  toJJLP  to  the  UV  nsaed  by  sv_*«  sour  escort; 


Evtnt:  Send/B(  ) 

or  Clott/l(  ) 

Actions:  trror(sv^l«len,  "Connection  closing*"); 

TRANS  re  RTtoJULF  to  the  ULF  nsutd  by  svJI*sourct^rt; 


Evtnt:  Active  Optn/*(  ) 

or  Active  Opto  idth  dsts/*(  ) 
or  Full  Fssslvt  Opsn/*(  ) 

Actions:  error (sv^*«lcn,  "llltgsl  request*"); 

TRANSFER^'toJULF  to  the  UIF  osasd  by  sv^**  sour  escort; 


Event :  NULL 

Actions:  Internal  Events 

1)  if  tiaeout  exceeded (sv^e) 

then  if  (UlF^tiieout^sction  •  1) 
then  *  “ 

temlnsteCsv  *,lcn,  *ULF  tiaeout*"); 

TRANSreR  teJTLF  to  the  ULF  nsaed  by  sv^**souree^rt; 
inltisliteCTv^*);  "" 

sv^** state  CLOSED; 
else  * 

report  tiaeout  (sv  *); 
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OR, 


2)  if  (conditions  exist  such  that  no  dsts  can  fas  exchanged 
by  local  state  aachines  ) 


then 


terainate(sv_A«len,  *^eryrice  failure,"); 

TRANSFER  toJfLP  to  the  ULP  naaed  by  sv  A.source^^rt; 
teniinate(sv_B,lcn,  "Service  failure, "T; 

TRANSFER  toJjLP  to  the  ULP  naaed  by  sv_B,source^^rt; 
itiitialite(7v_A);  sv^A, state  :•  CLOSED; 

initialite(svJB);  sv^B.state  CLOSED; 


OR, 


3)  if  (contents  sv^B.sendjqueue  have  all  been  transferred 

to  svjA,  re  enqueue*" end  subsequently  delivered  to  ULP  A  ) 
then  “ 

closini(  svjl.lcn  ); 

TRANSFER  toTULP  to  the  ULP  naaed  by  sv_A,seurce^ert; 


OR, 


4)  —For  clarity,  one-way  data  transport,  froa  TCP  A  to  TCP  B  is  shown, 
—Because  the  data  transport  service  is  syaaetric,  the  following 
—text  could  be  duplicated  to  represent  bi-directional  data  transport, 
—Note  that  TCP  B  is  still  respontible  to  reliably  transport  any 
—data  reaaining  in  svjl.sendjiueue. 


if  (the  data  exchange  between  local  state  aachines  has  been  triggered) 
then 

if  (svjl.sendjiirg  /•  0) 
then 

svji.recvjsrg  equal  i*  (sy^Btrecvjqueue^length  ^  sv^A.sendjirg); 


Dequeue  soat  portion  of  data  equal  to 
(aaount  aay  be  >*  0)  froa  svJ^.aendj)< 
and  append  to  svJI,recvj9ueu7;  * 


*aaeunt" 
^ueue 


if  (aaount  >  0) 
then 

svjl.sendjqueuc^lcnfth  svJ^.sendjtueuf ^length  -  aaount; 

sv^B.tecvjqueue^length  :•  sv“B.  recvj|ueue Yength  ♦  aaount, 

lf"*(syJ^.7endji7g  •<  aaount)"" 

then  s7^A,send^urg  0; 

else  sv*A,sendjirg  i*  syj^, sendjurg  -  aaount; 


if  (sy^A.send^^eh  •<  aaount) 
then  svjl.recv^ush  :•  svjB,  recy_^ush  ^  aaount; 
sv^A.send^^sh  0;"" 

else  sv** i.send^ush  :•  syj^.send^ush  *  aaount; 
try_^toJJe  liver; 


ms 


m 
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Sts ts  A  »  doling,  its te  B  ■  closing. 

Event:  Al</.\ LCN  ) 

Actions:  inltlell^eCsv^*); 

sv_^*,stutc  :’*’"CL0SED; 
teralnate(sv_*.lcn,  "User  Abort."); 

TRANSFER  toJJLP  to  the  ULP  nseed  by  sv^«.source__port; 

Event:  Allocste/*(  LCN,  OATA^LENCTH  ); 

Actions:  iv_*.recv_slloc  sv_*. recv^elloc  ♦  DATA  LENGTH; 
lf~ (sv^*.7ecvjqutue^lei^th  >“b) 
then  try_to^d7livtr7 


Event;  Send/*(  ) 

or  CloseAc  ) 

Actions:  error(sv^*. Icn,  "Connection  closing."); 

TRANSFER  toJULP  to  the  ULP  nsoed  by  sv^*.  source^^rt ; 

Event:  Active  Open/*(  ) 

or  Active  Open  vith  dAti/*<  ) 
or  Full  Psssiv#  Open/*(  ) 

Actions:  error<sv^*.lco,  "Illefsl  request.*); 

TRANSFER  toJULP  to  the  Ul^  nsaed  by  sv^^.source^^it; 

Event:  NULL 

Actions:  Internil  Events 

1)  —For  clsrity,  one-vsy  dsts  trsnsport,  froe  TCP  A  to  TCP  I  is  shoun. 

— iecsuse  the  dsts  trsnsport  service  is  s/Mstric,  the  following 
—test  could  be  dupllcsted  to  rt-present  bi-di reet ionsl  dsts  trsnsport. 
—Note  thst  TCP  E  is  still  responsible  to  rellsbly  trsnsport  sny 
*-dsts  rcAsining  in  svjl.sendjqueue. 

if  (the  dsts  exchsngs  between  locsl  ststt  •sehines  hss  been  triggered) 
then 

if  (sv^A.sendjurg  /•  0) 
then  " 

svjl-recv^urf  equsl  :•  (sv^E.recv^queue^length  ♦  svji.sendjirg); 

Dequeue  so«e  portion  of  dsts  equsl  to  "seount* 

(saount  esy  be  >•  0)  froe  svji.sei^^qutue 
snd  sppend  to  sv  l.recv  queue;  ** 
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if  (saount  >  0} 
thsa 

•vJl*Miidj9uttts_ltngth  :•  tv Jl.t«fidj9utu«_ltngth  -*  saount; 
•vJI.rcevjlusut^IeQgth  saount; 

If  (svJl.MQdjirg  •<  aaount) 

then  sT^AtsetSTjurg  <•  0; 

else  sv~A*Mfid3*rg  s*  sv^A*  sendjirg  -  eanunt; 

if  (svjA*eend,,ptteh  *<  eaount) 
then  s^ittecv^ush  <•  sv^ltreor^ush  ^  eaount; 
•snA«seBdl,_piish  !■  0;*“ 

eUe  se” ittend^iieh  <•  ev^A. send^push  -  eaount; 
try^tojleliuer;  ** 

08. 

2)  if  ((contents  eeJI.eendjiueue  heee  all  been  transferred 

to  ae  A.re^  quew  and  auhaequaotly  deliesred  to  UtP  A  ) 

4  *  “ 

(eottteata  svjl.aendjtueue  have  all  been  transferred 
to  svJI.re^jtueue  and  subsequently  delivered  to  UI»P  1  )) 

then 

teniioate(avJl«len.  Tonneetion  closed •**); 

THANSPII  tqJTlF  to  the  OLF  naeed  by  svjl.  source^rt; 
ttminate(s7  i.lcn,  Connect  ion  closedT*); 

TIUMSm  toJJlF  to  the  OIP  naeed  by  svJl.sottreej»ert; 
initialite(7vjl);  svj^, state  CLOSBDs 

initiaUte(sv*i);  sv^^state  CLOSCDs 

08. 

3)  if  tieeout  eaceeded(sy_*) 

then  if  (uDf^tiasout^aTtion  •  1) 
then  " 

teietnate(sv  *«lcn.  ULP  tiaeout.*); 

TAAHSPSh  to  the  OIF  naned  by  sy^*.source,^rt; 

inittaliie(Tv^*): 
sv  *•  state  ;•** CLOSED; 
else  “ 

reyort^tineout  (sv^*) 

—The  coeposlte  states.  aoS&O/tSTAILlSMID.  CLOSCO/OOSIlii;. 
-ACTlVE/ESIASLlSHeD,  ACriVE/aOSlNC.  FASSXVE/ESTASLISHED.  AND 
— FASSIVE/GLOSINC.  are  reached  after  abnorval 
—connection  teminatlon  caused  by  either  an  Abort  request  or 
—service  failure*  lecause  the  service  request  lists  for  ULF  A 
-"-already  appear  in  ocher  states,  these  lists  are  referenced  rather 
—chan  duplicated* 
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6.5.6.1.10  State  A  ■  doted,  iff  B  ■  tif blithtd. 

— ULP  A'a  aervict  requaat  list  appears  In  the  CLOSED/CLOSED  state. 

Event:  Seni/B(  LCN,  DATA,  DATA  LENGTH,  PUSH  FUG,  URGENT  FUG 
I  ,TIHE0UT1  ( .TiTfeOUTJiCnOK  17 

Actions:  if  (rooB  in(sv  B.send  queue}) 
if  (TI«0lf  /-  NULL) 
then  svJ8.ulp_tiMOut  :•  TIHEOUT; 
add_tojsendjqueue(sv  B); 
else  -  -  -  — 

error (  svjl.lcn,  "Insufficient  resources.**); 

TRANSFER  ToJJLP  to  the  ULP  named  by  svjl.source^^rt; 


Event:  Alleeate/B(  LCK,  DATAJXNGTH  ); 

Actions;  sv^B.recv^alloc  :■  sv^B. recv^aXloc  +  OATA^LENCTH; 
if^C s vjl .Tecvjqueue^Ieiii t h  >"0 )  * 

then  try_to^d7livtrT 


Event:  Cloee/B(  LCN  ) 

Actions:  sv^B.push  :•  sv  B.iendj^ueue^lenfth: 
sv*" B.stato  :•  dCoSING;**  “ 


Event:  Abort /B(  LCN  ) 

Actions:  tersinateCsv  B.lcn,  "User  abort.**); 

TRANSFER  toJTLP  to  the  ULP  named  by  sv^B.  source  Mrt; 
initialise(TvJI);  “ 

sv  B. state  :•** CLOSED; 


Event:  Full  Passive  Open/B(  ) 

Active  Open/B(  ) 

Active  O^n  uith  Data/B(  ) 

Actions:  error Csv^B.lcn,  "lUefal  request.*); 

TRANSFEFTtoJJU  to  the  ULP  named  by  svjl.source^rt; 

Event:  NULL 

Acetone:  Internal  Events 

I)  teminateC svjl.lcn,  "Remote  Abort."); 

TRANSFER  toJULP  to  the  UU  named  by  svjl.source^^rt; 
tntttalisedv^B);  ** 

sv  B.state  :**CLOSCD; 
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OH* 

2)  if  tlMOUC  MCSSdsdCsvJI) 

thsB  if  (otP^eiwout^sceloii  -  1) 
thtn 

t«cainsc«(tv  B*len,  "Utsr  tiMout.”); 

TRANSFER  to  ULP  to  tho  OIF  nsood  by  ivjl.  sour  comport; 

initi«liso(svJI); 

ivjl.ststo  :*** CLOSED; 

•lio  "* 

roport^tiMout  (svjl); 

8.5.8.1.11  Stsf  A  ■  closod.  itsf  1  ■  cloitog. 

—01/  A*i  Mtvieo  roqutst  list  ipposrs  in  tht  CLOSED/CLOSED  ststt. 
Busat:  Abort /•(  LCN  ) 

Aetiono:  tomin«to(sv  l.len,  Usor  Abort.**); 

TRANSFER  toJJlF  to  tho  ULF  noMd  by  ov^l.sourco^port; 

iiiitlolito(Tvjl); 

sir  i.stoto  !•  CLOSED; 


Eoont:  Allocoto/K  LCN,  DATAJ.B1ICTH  ); 

Aei;ioiiot  iv  l.roev  olloe  :•  i.roar^alloc  ♦  DATA^LENCTN; 

if“’Ci1rJI.7iCVJ^uouo^l•n|th  >  0)  thon  try^to^dsliiror; 


Euottt:  Clooo/K  LCN  ) 
or  Sond/K  LTN  ) 

Actions:  orrorC  sv  l.len,  "ConnoetioA  elostni."): 

TRANSFER  ToJJLF  to  tho  ULF  noiood  by  so^R.sourco^rt ; 


Evont:  Full  Fossivo  Opon/i(  LCN  ) 

Actios  Opoo/K  LCN  ) 

Activo  O^ft  with  Doto/B(  LCN  ) 

Actioso:  orrorC  sv  l.lcii.  *Xllofil  roquoot.*): 

TRANSFER  ToJJLF  to  tho  ULF  ooMd  by  svjl.sourco^ri; 


Evont:  NULL 


Actions:  Intornol  Evont $ 

1)  toroinotoCsvJI.Icn,  "Rowoto  Abort.’); 

TRANSFER  toJlLF  to  tho  OLF  noaod  by  svjl.sourco^^rt; 

initiollso(7v^B): 

sv  I.stoto  {•*”CLOSCD; 
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OR, 

2)  if  tiacout  txetadadCty^B) 

thtn  if  (uD^tiwout^aetion  •  1) 
than  *  * 

ttniisiatt(avjl«lcn,  *Ut«r  tlMout,*); 

TRANSFER  toJlLF  to  tho  0LP  naiad  bf  tyjlttourei^^rt; 
initialiteCav  B  );  * 

av  Btitata  :*  ^OSED; 
alaa  ~ 

raport^tiaaout  (av^B); 

6.5.6,1.12  Btata  A  ■  activa,  atata  B  ■  aatabliahad, 

— ULP  A'a  aarviea  raquaat  liat  appaatt  in  tht  ACTIVC/CLOSED  atata* 

Evant:  $and/B(  LCN.  DATA,  DATA  UNGTR.  PUSB  FLAG.  URCENT  FUC 
I, TIMEOUT J  I,TX?feOUTJkCrXONjT 

Actiona:  if  (rooa  in(av  B*aafid  quaua) 

if  (TxneouT  /•  wH) 

this  ayjl.ulp^tiaaout  !•  TXMCOUT; 
add  tojtandjqMutCav^B); 
alaa  —  -  -  — 

arrorC  avjl.lcn,  *IiiauffUianc  raaourcaa**); 

TRANSFER  ToJJLF  to  tha  UU  naaad  by  ivjl.ioorea^rct 


Evant t  Cloaa/B(  ICN  ) 

Actiona:  avj|,put>j  avJB*aandjtuaua^lan|th: 
•V*” B* atata  t*  (SoSXNG; 


Evtnc  Abort /B(  ICN  ) 

Actiona.  tamtnata(av^B.lcn,  ^aar  abort**); 

fRAKSFER  toJFlF  to  tha  ULF  naaad  by  av^B.aourcajwrt: 
lnitlallaa(7vjl);  ** 

av  B* atata  CLOSED; 


Evant:  Allocata/BC  LCN.  DATA^UNCTM  }; 

Actiona:  av^B.racy^aUoc  :•  avjl.raev^alloc  ♦  DATA^LENCTN; 
lf""(av^B.7acvjqwaua^lan|th  >"0)  " 

thtn  try  to  dalivarT 


Event:  Full  Faattv#  Opan/B<  ) 
Activt  Optn/!l(  ) 

Active  Open  with  Data/B(  ) 
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AetiOMz  •rrorltv  8.1ea,  "lllMil  r«4UMt.*): 

TRAIISriR*toJIV  to  tbi  ULP  iMt4  bjr  tvjl.oottretj^n; 


I^ot:  HULL 

Act  loot  z  ZttttnioX  Ivooto 

1)  ttrBlfuite(av  I. leu*  tt«oto  Abort.*); 

TAAKSFER  to  7lp  to  tho  UUP  Mtd  bf  ovJl.aoyreojM^rt; 
initiollMCivJI); 

•V  i.ttACo  z«** CL08ID: 


08* 

2)  if  tlatout  tiict«io4(ivJI) 

tKtfi  II  (uD^ti«iO«t^octloci  •  1) 

Chon  ** 

tominoeoCtv  I. leu*  "Uaor  ciMout.*); 

TIAIlSfCt  to  Fir  to  tho  «U  OMod  bjf  ov^l.oottrco^rt; 
ini till lit (ivjl); 

•ojl.itoto  z«  CLOifO; 
oloo  "" 

ro^art^tlMoat  (oojl); 


08. 

))  if  -tiaooiic  metododCtvJ^) 

th^  II  (Ul>^tl«ioiit^octloo  •  1) 

thv  0  *  * 

ttmloottCoo  A.lcfi.  Uotf  tiflooiit.*); 

TRAIIsrCR  tojn^  to  tho  ULF  00904  by  f ojl.  tooreo^rt ; 

loitiolito<7vjt): 

ov  A«atoto  :*•  CLOSCO; 

OlM 

royort^tiwouc: 

8.5.8.1.I3  Stott  A  •  octi^.  ototo  8  *  cloolog. 

A*i  oorvico  roqyott  Uot  ofpoorr  lo  tho  ACTIVS/OOSO)  ototo. 

Cvofit:  Soo4/8(  ) 

or  Clooo/8<  ) 

Actlooe:  orror<ov  S.leo.  Xooooetioo  clootog.*): 

78AASrC8**to  UIF  to  tKo  rtF  iioMd  by  oojl.ooyreo^rt ; 


tvoot:  AUooito/i(  Uh.  UATA^rNCTb  ); 

Actlooo:  ov^S.rocv^olloc  :•  oo^t.  tfcv^olloe  ♦  OATA^tChCTK; 

lf“(o»^8.Tocv^O'*0'*o_,^^t‘‘  '^0) 
thoo  try  to  4oUoor7 
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Cv«nt!  Abort /i(  LCK  ) 

Aetioois  B.lcii»  *V0tr  Abort.*); 

TRANSPER  to  Ttf  to  Cht  VLF  naaod  by  Av  R.touretport; 
liilttillit(fv_8); 

•V  8. tut#  CLOSED; 


Evtfit:  Full  Fattlvo  Oyon/K  ) 
or  Actlvf  Opoii/B(  ) 
or  Actlvf  O^n  with  Dtt«/I(  ) 

Actions:  error (tYjS. loo,  *Ulei«l  roAvoet.*); 

TRAKSFElTtoJIlF  to  the  ULF  oeaeA  by  evji.  tour  cohort ; 


Event:  NUU 

Actions:  Xnternil  Events 

O  ter«instt(sv  B.len,  *Re«oce  Abort* *>; 

TRANSPER  toJJlF  to  the  DIF  Mstd  by  iv  i.source  »ort; 

initisUte(7v^i); 

sv^R.stste  !•** CLOSED; 

OR, 

2)  if  ttato;r  esceoAtACsvJI) 

the  if  (Ut^tia»oet^se?ioA  •  l> 
then  *  "" 

ttminsteCsv  l.len,  *Vstr  tteoitt.*); 

TRANSPER  toJJlF  to  the  OLF  asmA  by  sv  l.soMrcs  Mrt; 

inlti«lise(sv_|): 

sv  S.stste  CLOSED; 

else 

reyoit^tiAsoet  (sv^B); 

OR. 

3}  if  tUwouc  encteSeSCsvJ^) 

the  if  (DlJ^tiasoet^scTion  •  1) 
then  ^  “ 

ttniinsttCsvjk.left.  llser  tiatoet.*); 

TRANSPER  to  DLF  to  the  DLF  nseoA  by  sv  A.  source  Mr t ; 
initioltseCTvj^);  “ 

sv  A.stsce  t«*CLOSED; 
else  ** 

m^ort^tiatoet  (svj^); 

S.S.S.l.ii  Stsce  A  •  Mssive>  stote  B  •  estoblishoA. 

—ULF  A*s  reteeet  list  esseofi  in  the  FASStVE/CLOSO  sute. 


SO 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985. 


MIL-STD-1778 
12  August  1983 

6.5.6.3.1  Add  to  send  queue  (tv*).  The  add^tojiendjiueue  set ion  procedure 
enqueues  the  data  provided  in"*an  Active  Open  idth“Data  or  Send  request  onto 
the  aendjqueue  of  the  state  vector  naaed  by  paraaeter.  The  data  effects  of 
this  procedure  art: 

-  Data  csaisined: 

froB  DLP.data  froaJUlP . urge nt_f lag 

froaJJ^*  <**ta_length  froaJJLP.push^fTag 

-  Data  modified: 

sv  *.8end  queue  sv__**send^ush 

sv^*,  sendjqueue^length  sv^*,  send^urg 

—Add  the  data,  urgent  and  push  inforaation  provided  by  the  UIP 
—in  a  SEND  to  the  sendjqueue  of  the  state  vector. 

Enqueue  contents  of  froaJJLP.data  to  sv_/. sendjqueue,  staaping  each 
data  octet  with  the  current  tine; 

av  *.sendjqueue__length  :•  sv^^.sendjqueue^length  ♦  froaJJlP.data^length; 

if  (froB_DLP.push__flag  •  TRUE) 

then  sv^J.send^^puTh  :•  sv^^.sendjqueue^lenfthj 

if  <fraBj[7lP.uriant_^flag  ■  TRUE) 

then  sv_/.iendjarg  :•  sy^^.sendjqueue^leogthj 

6. 5. 6. 3.2  Aisiw  new  len.  The  asiignjieijlcn  action  procedure  assigns  a 
local  connection  naat  not  currently  uied*”for  a  new  open  request  and  subsequent 
connection.  The  data  effects  of  this  procedure  are: 

-  Data  examined:  internal  resources 
Data  modified:  none 

—The  procedure  returns  the  value  to  be  used  as  the  new 
—local  connection  name. 

6.5.6.3.3  Error  (local  connection  name,  error  description).  The  error 
action  procedure  copies  the  local  connection  naat  and  error description  text 
supplied  by  parameter  into  the  toJJLP  structure.  The  service  response  field 
is  assigned  to  ERROR  for  subsequent  transfer  to  the  ULP.  The  data  effects 
of  the  procedure  are: 

•  Data  examined:  procedure  parameters 

-  Data  modified:  tc^ULP.lcn,  toJJlP.error^desc,  toJJLP.servlce^response 

toJi^l^.lcR  :■  local^connectionjsaae; 
to3^LP.error_^desc  error_des?riptioo; 
co^'ULP.servi'ce  response  ERHOR; 
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6. 5.6.2  Dscislon  functions.  Ths  dsclsion  functions  rtprssent  condition 
checks  Bsde  In  several  places  in  the  service  state  machine  definition. 

6. 5. 6.2.1  Room  In  (state  vector  name).  The  room^ln  decision  function 
compares  the  amount  of  space  available  In  the  sendji^ueue  of  the  state  vector 
(named  by  the  parameter)  against  the  amount  of  data  provided  by  the  ULP  In 
an  Active  Open  with  Data  or  a  Send  service  request.  The  data  effects  of 
this  function  are: 

**  Data  examined: 

f  r  omJJLP .  da  t  a_le  ng  t  h  SI2EJ)P_SENDJIES0URCE  S 

ov^*.sendjqueue^length 

-  Return  values: 

FALSE  -  Tha  sendjqusue  cannot  accommodate  all  the  data 
provlded^ln  tha  servlca  request. 

TnJE  -  There  Is  enough  room  in  the  sendj^ueue  for  the  data. 

If  (fronJTLP.data^length  > 

(SIZEJDF^SEND^RESOURCE  -  sv_^*.send  queue  length)) 
then  return  (FALSE)  "*  —  —  — 

else  return  (TRUE); 

6. 5. 6. 2. 2  Timeout  exceeded  (sv*).  The  tlmaout^exceeded  dsclslon  function 
compares  tha  current  time  against  tha  age  of  the  dita  In  the  sand  queue  and 
tha  specified  ULP  timeout  l^mlt  to  datatmlne  If  the  ULP  timeout  Kas  been  ex¬ 
ceeded.  The  data  effects  of  this  function  are: 

-  Data  examined:  sv_*.ulp_tlmeout  sv_*.sendjquaue 

-  Return  values: 

FALSE  -  The  data  In  the  sandj^ueue  does  not  exceed  Che  ULP 
defined  timeout  llml?. 

TRUE  -  Data  In  tha  send^queua  has  exceeded  Che  timeout  limit. 
*-The  data  at  the  front  of  Che  queue  Is  tha  oldest. 

If  (sv  *.send  queue^langth  >0) 

then  iT  (CURrKtJTIKE  >  sv^*.sendjqueueIO] timeout  ♦  sv  *.ulp  timeout) 
then  returo"‘(TRUE)  “  * 

else  return  (FALSE); 

6*5. 6. 3  Action  procedures.  These  routines  appear  In  several  places  In 
the  service  machine  definition.  The  *****  can  be  replaced  by  either  A  or  1  for 
delivery  to  the  appropriate  UIP, 


S3 


1-213 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


MIL-STD-1778 
U  August  1983 


6.S.6.1.15  Stats  A  ■  passive,  state  B  •  closln 


— ULP  A*s  request  Ust  appears  In  the  PASSIVE/aoSED  state. 

Event!  Allocate/B(  LCN,  DATAJLENCTH  ); 

Actions:  sv_B.recv_alloc  !-  svJB.recv^alloc  +  DATA  LENGTH; 

If  (sy_B.*recv__^queue_length  >“0)  ** 

then  try^to__dellver7 

Event:  Abort /B(  LCN  ) 

Actions:  teralnate(sy_B.lcn,  User  abort."); 

TRANSFER  to  ULP  to  the  ULP  naaed  by  sv  B. source  port 

lnltlalite(7v_B); 

svjl. state  :*’’CLOSED; 


Event:  Close/B(  LCN  ) 
or  Send/B(  LCM  ) 

Actions:  errorC  sv^B.lcn,  "Connection  closl:«."); 

TRANSFER  to^ULP  to  the  ULP  naaed  by  svjl.  sour  carport 

Event:  Full  Passive  Open/B(  LCN  ) 
or  Active  Open/B(  LCN  ) 
or  Active  Open  with  Data/B(  LCN  ) 

Actions:  error(  sv^B.lcn,  "Illegal  request."); 

TRANSFER  toJULP  to  the  ULP  naaed  by  sv^B.  sour  escort 


Event:  NULL 

Actions:  Internal  Events 

1)  termlnsteCsv^B.lcn,  "Reaote  Abort."); 

TRANSFER  to^ULP  to  the  ULP  naaed  by  iv  B.sourceport; 
inltlallse(7v_B);  ” 

a*'  B. state  t-^CLOSQ); 


2)  If  tlaeout^exceeded(svJB) 

then  If  (ULP^tiaeout^actlon  •  1) 
then  “  " 

tetalnate(sv__B.lcn,  "User  tiaeout."); 

TRANSFER  to^ULP  to  the  ULP  naaed  by  sv  B. source  port; 
lnltiallse(7y_B);  ”  “ 

sv_B. state  !«’"C10SED; 

else 

report  tiaeout  (sv  B); 
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Evtnt:  Send/BC  LCN,  DATA,  DATA  LENGTH,  PUSH  FLAG,  URGENT  FUG 
C, TIMEOUT )  [,TliiEOUT_ACriONl7 

Actloni:  If  (rooB  in(tv  B.ttnd  queue) 

If  (TIMEOUT  /•  NULL) 
then  iv^Jl.ulp^tlaeout  :•  TIJCOUT; 
ad  djt  ojie  nd jiueue  (  a  v^B  ) ; 

else  ” 

errorC  av^B.lcn,  "Iniufficlent  resources •**); 

TRANSFER  ToJJLP  to  the  ULP  naaed  by  av_B.iource_port ; 


Event!  Cloee/B(  LCN  ) 

Act  Iona:  av_B.push  avJI«aendj)ueue^Iangth; 
av“" l.atate  :•  CLOSING;""  “ 


Event!  Abort /B(  LCN  ) 

Actions:  tenlnateCav  B.Ien,  "User  abort."); 

TRANSFER  toJlLP  to  the  ULP  naned  by  sv^B.sourcejiort; 

initlallte(Tv_B); 

sv  B. state  CLOSED; 


Event!  AlIocate/B(  LCN,  DATAJJENGTH  ); 

Actions:  svjl.recv^alloc  !•  svJB.recv^alloc  ♦  DATA^^LENGTH; 
if^Csv^B.Tecvjqueue^^length  >*0) 
then  t7y  to  deliverT 


Event:  NULL 

Actions:  Internal  Events 

1)  teniinsteCsv^B.Icn,  "Remote  Abort.*); 

TRANSFER  toJlLP  to  the  ULP  named  by  svjl.source^ort; 
lnitlsIlse(7v^B);  ” 

svjl. state  !'>*”CL0SES; 

OR. 

2)  if  tlaeoutjixceedid(sv_B) 

the  if  (ULF^tliMOutjiCtion  *«  1) 
then  ""  “ 

tenilntte(svJB.Icn,  "User  timeout.*); 

TRANSFER  toJTLP  to  the  ULP  named  by  sv_B.source_port ; 
inltialise(7v_B);  “ 

svJB. state  :■** CLOSED; 
else  “ 

report  timeout  (svJB); 
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6.5«6.3.4  Load  ncurlty.  The  aacurlty  paraMtan  (Including  aacurlty 
Itvtl,  coapartacnc,  traraalsalon  control  coda,  and  handling  raatrictiona)  In 
an  IncoBlng  aagnant  art  loadad  Int?  the  atata  vector.  The  data  affacta  of 
this  function  are: 

*  Data  axaalnad: 

fraa_NET* opt Iona  [aacurlty] 

*  Data  eodlfitd: 

•v.sec 

—This  would  occur  after  a  successful 
— secure  ngejeat  ch. 

sv.sac  :■  froa^HET. options  [security] 

6.5.6.3.5  Inltlalltt  (sv*)»  The  Initialise  action  procedure  clears  all 
values  of  the  state  vector  naaed  by  paraaeter.  The  data  effects  of  this 
procedure  are: 

*  Data  examined:  procedure  paraaeter 

-  Data  aodlfled:  all  fields  of  sv^* 

daq  uaue  ( s  v^* .  se  nd jq  ueua ,  s  v^*  •  se  nd jqueue^lc  ng  t  h ) ; 
dequeue  ( sv""*.  re  cvjqueue ,  sv“*^  re  cvjqueue^le  ngt  h ) ; 
sv_*  :•  aiTljitate^vector;’"  “  * 

6.5.6.3.6  Open  fall  (local  connection  naae).  The  opsn^fall  action  pro^ 
eedure  copies  the  local  connection  nans  supplied  by  paraaeter  and  the  0PEN_ 
PAIL  service  response  Into  tht  toJJLP  structure  for  subsequent  transfer  toT 
the  ULP.  The  data  effects  of  thl7  procedure  are: 

-  Data  examined:  procedur<^  paraaeter 

-  Data  modified:  toJILP.lcn  toJEIlP.servlce^responee 

toJJLP.lcn  :*  locsl^connectlon  naae; 
toTDiP^fervlce^reaponse  :•  OPBir_rAIL; 

6.5.6.3.7  Open  Id  (local  connection  nams>  source  port,  source  address, 
destination  port,  destination  addr).  The'"open  Id  action  procedure  copies 
the  paraacters  and  the  OPEK^ID  service  responsT  into  thu  toJJLP  structure 
for  subsequent  transfer  to  The  ULP.  The  data  effects  of  thTs  procedure  are: 

Data  examined:  procedure  paraaeters 
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Data  Bodlflad: 

toJJlPtlcn  toJILP.strvica^raaponse 

to^nJP  t  sour  ca_^rt  toJJLP  •  4ts  t  lust  lonjport 

toJJlP  .sourctjiddr  to^ULP  •das  tinatlon^sddr 

toJJLPtlcn  Xocaljeonnaccion^naMi 

toJILP*  sour  cavort  :■  source,j»ort: 
to^ULPtSourca^addr  :■  sourca_addrass; 
toJJLPtdastinatlon^ort  t"  fstlnstionj^ort; 
to3ll^*dasCitiatloo_addr  :■  dastinatiou^addr; 
toJJUtsarviea^ras'^nsa  :■  OPEN^ID; 

6.5.6«3.8  Opan  suceass  (local  connaction  naaa)#  Tha  opanjiuccass  action 
procadura  eopits  tha  local  connaction  naaa  suppliad  by  paraslatar,  and  tha 
OPEN  SUCCZSS  sarvica  rasponsa  into  tha  toJJLP  structura  for  subsaquant  trsnsfar 
to  tRa  UlPt  Tha  data  af facts  of  this  procadura  ara: 

-*  Data  axaninad:  procadura  paraastar 

-  Data  aodifiad:  toJiiP.lcn  toJILP.sarvlcajrasponsa 

toJJLP.lcn  locaL.connaction_naaa: 

to^Ulf  •saivica^ras|Mnsa  :■  GPET^SUCCESS; 

6.S.6.3.9  Eapoft  tiaaout  Tha  raportjtiaaout  action  procadura 

inforas  tha  UUP  that  a  ULP^tiaaout  has  oecurrad."”  Tha  oldest  data  in  tha  sand 
ouaua  is  raquauad  and  tha  Tiasout  tias  rasst* 

Tha  data  af  facts  of  this  function  arai 

-  Data  axaainadt 

-  Data  aodifiad: 
bagin 

arrorCsv^*# lcn,“ULP_tiaaout ) 

transfer** toJJtP  to  Tha  ULP  naaad  by  sv^*^sourca^rt ; 
raq  ueuajolf s  t  (sv^* ) ; 
and;  *  ~ 

6«5t6«3.l0  REQUEUE  OLDEST  (sv  *);>  Tha  raqusua^oldtst  action  procadura 
raaovas  tha  oldest  data  froa  tha  sandjiuaua  a^  raquauas  tha  data,  ashing  it 
the  youngest*  ** 

Tha  data  affects  of  this  procadura  ara: 

•  Data  axaainad: 

sv**sand  queue 
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6.5.6.3.11  Tcrainatc  (local  connection  nue,  dcicrlption).  The  terminate 
action  procedure  copies  the  local  connection  name  and  description  supplied 
by  parameter,  and  the  TERMINATE  service  response  into  the  to^ULP  structure 
for  subsequent  transfer  to  the  ULP*  The  data  effects  of  thlT  procedure  are: 

*  Data  examined:  procedure  parameters 

-  Data  modlflmd: 

toJJLP  •servlcejresponse  to^ULP  •  Icn 

to3JLP*error_^sc  ~ 

toJJLP«lcn  :*  local^connection^naae; 
to3^lP«error_desc  description; 
toJ^lP.serviOe^response  :•  TEFMINATE; 

6.5.6.3.12  Sec  range  match?  The  sec^rangejaatch  function  checks  if  the 
security  parameters  (including  security  level,  compartment,  transmission 
control  code,  and  handling  restrictions)  In  the  Incoming  segment  fit  within 
tM  security  ranges  specified  In  the  security  list. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

fromjnet* opt Ions  [security]  su.sec^ranges 

-  Return  values 

NO  The  values  In  the  Incoming  segment  are  not  within  the 
ranges  specified  In  Che  state  vector. 

TES  —  The  values  In  the  incoming  segment  are  within  the 
ranges  specified  In  the  state  vector. 

6 .5 .6 .3. 13  Record  open  parameters  (ULP  identifier,  open  mode).  The  record 
open^parameters  action  procedure  copies  the  values  provided  by  Che  ULP  In  an 
open""rsquesc  to  Che  state  vector.  The  data  effects  of  this  procedure  are: 


Data  examined: 

f  r  omJULP  •  sour  ce^ort 

fromJULP .precedence 

f  romJLILP .  source^addr 
from  ULP.tlmeouT 

fromJ^LP. security 

Data  modified: 

sv__*.  source^ort 

sv^*.orlglnal_prec 

sv^*.  source^^addr 

sv**.  security 

sv”* ,  das  t  Ifiat  lon_^''rt 

sv“*. timeout 

sv^*. dcst Inat looked dr 

sv^*.  open^mode 

— Record  the  socket-pair  and  connection  information 
—provided  In  the  open  service  request  In  the  state^vector. 
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iv_*.port  :■  £ro«J[JLP,iourct_port; 
tv^*»sddr  :■  tht  addrtss  of  this  TCP; 
sv***op«n^aode  :■  optnjK>dt; 

—Record  tlatout,  security »  end  precedence  for  ULP  * 

**lf  provided,  otherwise  ssslgn  defeult  values; 

if  (free  ULP. security  /■  NULL) 

then  svj^« security  :■  froaJULP .security 

else  sv^*. security  :•  DEF^LT^SECURITY; 

if  (froeJiJLP. see. ranges  /■  NULL) 

then  sv^.sec^ranges  :■  from  ULP.sec^rangts 

else  svj^.sec^ranges  :■  lEFAULTjSBC^JlANGES ; 

if  (froBjULP. precedence  /■  NULL) 

then  sv_J.original^rec  :■  froa  ULP. precedence 

else  sy**.original_prec  UEFAifLTJPRECEDENCE; 

if  (froB  ULP.tiseout  /-  NULL) 

then  sv  '^.ulp  tiaeout  :•  froa  ULP.tiaeout 

else  svj*.ulp*tiaeout  IXFmTjrXKEOUT; 

if  (sv^*.openjBode  /■  UNPASSZVE) 

then  s\^*.des7instion_^ort  froaJJLP.destination^ort; 

sv^*.destination_addr  froa^ULP.destinstion^addr; 

else  svj^.destinstion^ort  :•  NULLT  ** 

sv**.destination_addr  :•  NULL; 

6.5.6.3.14  Try  to  deliver.  Tht  try^^tojdt liver  action  procedure  detesaines 
froa  the  receive  allocation,  the  receive  Queue  site,  and  the  receive  push 
and  urgent  variables  how  auch  data  to  deliver  to  the  local  ULP.  This  pro^ 
cedure  is  called  froa  several  places  for  both  ULP  A  and  ULP  B  in  the  service 
aschlnt  definition.  Where  the  sv_*  notation  is  used,  the  appropriate  state 
vector  naae  should  be  replaced.  The  data  effects  of  this  procedure  are: 


-  Data  examined: 

s  .  sour  ce jort 

-  Data  aodified: 

to JJLP.dat  a 

sv^*.  reev^ush 

toJlLP.  datable  ngth 

sv~*.  reev^urg 

to“ULP  .urgelitjflag 

svj*.  recv^alloc 

toJULP.lcn  ~ 
sv^v.  recvjqueue 

sv**.  recvjQueue^length 

—The  aaount  of  data  delivered  is  based  on  the  aaount  of  pushed 
'**data  waiting  and  the  receive  allocation. 


if  (sv^*.recv_push  /■  0) 

then  —As  auch  pushed  data  allowed  by  the  reev  allocation 
—is  delivered. 


MILITARY  STANDARDS:  TCP 


MIL-STD  1778 


MIL-STD-1778 
12  August  1983 


if  <sv  ♦•recv  alloc  >  sv  *«rtcv  push) 
then  “  ~ 

toJJLP»(Uta^langth  :•  av^^.rtcv^ush; 

•v~*.r#cvjush  :■  0; 

tltt 

toJJLP.data_langth  :■  sv^^.rtcv^^alloc; 
sv^*.rtcv  push  :■  sv^*.  r7cv_^ush  -  toJJLP.data^langth; 
also  —Without  a  PHSU,  thoro  Ts  oo  guarantac  o7  dalivaiy* 

**Dallvar  sons  amount  of  data  lass  than  or  aqual  to  racalva 
--allocation  (possibly  sons). 

toJ3LP.dats_langth  :»  soma  valua; 

if  (toJJLP.data^langth  /■  0) 

than  — Updata  ststa  vector  alamants  and  prapara  data 
—and  paramatars  for  dslivary. 
toJJlP.lcn  :■  sv^*.lcn; 

—Urgant  data  cannot  ba  dslivarad  follovad  by  non-urgant  data* 
—If  “and-of-urfint"  falls  in  data  to  ba  daliwsrad,  maka 
—two  separata  dalivarias* 
if  ((sv^*,racv_urg  /■  0)  and 

(svj^.racv^irg  <  toJJLP*data^langth)) 
than  ba^n  —  -  — 

— Oalivar  urgent  data  alone* 
save  !•  toJJlP.data^langth; 
toJJLP  ♦datT^langth  T»  sv^*.  raev^urg; 
sv^**  racv^u7g  .*•0;  " 

toJJLP* urge nt_f lag  :■  falsa; 

Dequeue  toJILP.data^langth  octets  from  sv^*,  racvjquaua 
and  place  in  toJULP.data;  **  ” 

sv^*,racv^alloc  :-"sv^*.racv^alloc  -  toJULF •  detail 4 ngth; 
sv^*,  racvjquaua^langth  :■  sy^*.  racvjquavia^langth^- 

toJJl*?*  dats^langth; 
TRANSFER  toJULP  to  the  UUP  named  by” sv^*.sou7ca^port; 

—Prapara  to  dsllvar  remaining  non-urgant  data. 
toJULP.data^langth  save; 

atff;  ” 

—If  urgent  data  follows  the  data  being  dalivarad»  inform  UUP* 
if  (sy_^*,racv_urg  >  toJJLP.data^langth) 
than  ”  ”  ^  ~ 

toJDLP .urge nt_f lag  :•  TRUE; 

sv”*.racv  urg”:»  sv  •.raev  urg  -  to  ULP.data  length; 
else  -  — 

toJJLP.urgant_flag  :•  PaLSE; 
sv^*, raev  urg”:*  0; 
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Ds^utue  toJULP.dsts^lsngth  oetsts  froa  sv  *.rtcv  qutut 
and  place  in  to^ULP.dsta;  “  " 

iv_*.recv_alloc  i-* iv  *.recv_alloc  -  to  ULP.data  length; 
fecvjqueue^length  :■  av2*.recvjjueue_length“- 

to japTda  t  a_langt  h; 
TRANSFER  tojffl^  to  the  ULP  naaad  by  ay^*.sourcejK)rt; 
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7.  SERVKZS  REQUIRED  FROM  LOWER  UYER 

7.1  Goal*  Ths  goal  of  thla  aactloii  is  to  daaerlba  tha  alniaua  sot  of 
sorvicos  raqulrod  of  tha  oatwork  layar  protocol  hy  TCP*  Tha  sarvleas  raquirad 

ara: 

a.  data  transfar  aarvica 
b*  ganaralisad  natirotk  aarvica 
c«  arror  raportiog  aarvica 

7.2  Sarvica  dascriptiona*  A  dascriptien  of  aaeh  aarvica  fellows. 

7.2.1  Data  transfar  M^ica.  Tha  lowar  layar  protocol  auat  provide  data 
transfer  bstvaan  tCP  •odulas  in  a  cooaunieation  systtB.  Such  a  aystao  say 
consist  of  a  single  network  or  a  sat  of  inter connect ad  networks  forming  an 
intamat.  Data  must  arrive  at  a  destination  with  nonrsaro  probability;  soma 
data  loaa  may  occur.  Tha  data  transfer  sarvica  is  not  raquirad  to  prasarva 
tha  order  in  which  portions  of  data  ara  supplied  by  tha  source  upon  dalivary 
at  tha  destination.  Data  daliwirad  ia  net  necessarily  arrer*fraa.  Tha  lower 
layar  protocol  must  provide  data  transfer  throughout  tha  systsB*  TCP  need 
only  supply  global  addressing  and  control  information  with  each  portion  of 
data  to  be  dslivarod.  Routing  and  network  specific  charact aria ties  art 
handled  by  tha  network  layer  protocol.  For  example,  TCP  need  net  be  aware 

of  current  topology  ot  packet  siae  restrict ions  to  transmit  segments  through 
a  particular  network. 

7.2.2  Ceyraliaed  network  service.  The  lowar  layar  protocol  must  provide  a 
means  for  tc?  to  select  from  tha  transmlssien  sarvica  qualities  provided  by 
tha  coimtfiicatioo  system  for  each  portion  of  data  delivered.  Tha  transmisaien 
quality  paramatars  must  include  precedence.  Also,  tha  lower  layer  protocol 
must  provide  a  means  of  labelling  each  portion  of  data  with  security  informs* 
tion  including  security  level,  compart mentation,  handling  restrictions,  and 
transmission  control  coda  (i.e.,  closed  user  groups). 

7.2.3  Error  raportini  service.  The  lower  layer  protoco  oust  provide  error 
reports  to  TCP  indicating  dtscontimtation  of  tha  above  sarvicas  caused  by 
catastrophic  conditions  in  this  or  lowar  layer  protocols. 
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8.  LOWER  UYEK  SERVICE /INTERFACE  SPECIFICATIONS 

8.1  Cofcl.  Th«  ftoal  of  this  saccioo  is  to  spscify  tht  ■Iniaal  subnttvork 
protocol  ttrvicAs  x  '^ulrsd  by  TCP  and  tht  latarfact  through  vhich  thoat 
atrvlctt  are  access The  first  part  defines  the  interaction  primitives 
and  their  paraeeters  icr  the  lower  interface*  The  second  part  contains  the 
abstract  aachlne  specification  of  the  lower  layer  services  and  interaction 
discipline. 

8.2  Interaction  primitives.  An  Interaction  primitive  defines  the  purpose 
and  content  of  information  exchanged  between  two  protocol  layers.  Two  kinds 
of  primitives,  based  on  the  direction  of  information  flow,  are  defined. 
Service  requests  pass  information  downward;  service  responses  pass  informs** 
tion  upward.  These  primitives  need  not  occur  in  pairs,  nor  in  a  synchronous 
manner.  That  is,  a  request  does  not  necessarily  elicit  a  "response”;  a 
"response*  may  occur  independently  of  a  request.  The  information  associated 
with  an  interaction  primitive  falls  into  two  categories:  parameters  and 
data.  The  parameters  describe  the  data  and  indicate  bow  the  data  is  to  be 
treated.  The  data  is  not  examined  or  modified.  The  format  of  interaction 
primitive  information  is  implementation  dependent  and  so  is  not  specified. 

A  given  TCP  implementation  may  have  slightly  different  Interfaces  imposed 
by  the  nature  of  the  network  or  execution  environment*  Under  such  cireum* 
stances,  the  primitives  can  be  modified  to  include  more  parameters  or  addi¬ 
tional  primitives  can  be  defined.  However,  all  TCFs  must  provide  at  least 
the  interface  specified  below  to  guarantee  that  all  TCP  implementations 
can  support  the  same  protocol  hierardiy. 

8.2.1  Service  request  primitives.  A  single  service  request  primitive  is 
required  from  the  network  protocol,  NETJSCND. 

8.2. 1.1  NET  SEND.  The  NETJSEND  primitive  contains  complete  control  infor- 
mstion  for  each  imit  of  data  to  be  delivered.  TCP  passes  in  a  NET^SCKD  at 
least  the  following  information: 

**  sddress  -  address  of  TCP  sending  data. 

b.  destination  address  •  address  of  the  TCP  to  receive  data. 

e.  protocol  -  identifier  assigned  to  recipient  TCP. 

indicators  -  relative  transmission  quality 
associated  witK  teiit  of  data. 

-  precedence  *  one  of  eight  levels:  (PO,  Pi,  P2,  P3,  P4,  P5, 
P8,  P7)  where  PO  <•  PI  <•  P2  <•  P3  <•  P4  <•  P5  <•  P6  <•  P7, 

-  reliability  one  of  two  levels:  (tO,  R2)  where  tO  •  oovmal 
reliability  and  Rl  •  high  reliability. 

*  delay  -  one  of  ewe  levels:  (DO,  Dl)  where  DO  •  novmal  delay 
and  Dl  •  low  delay. 
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-  throughput  -  ont  of  two  Xtvals:  (TO,  Tl)  whoro  TO  •  Qon»l 
throughput  ond  Tl  •  high  throughput. 

i^tPtifUr  -  trolut  distifigulihlag  this  portion  of  dots  froa 
ethtit  Mat  by  this  OIP. 

frsgasnt  Indicator  -  flag  shoving  vhtthar  tha  nttvork 
protocol  MO  iragasnt  data  to  accoapUsh  dtllMry. 

g,  tiat  to  liva  -  aalua  In  Mconds  indicating  aaxiaua  Ufatiaa  of 
Tm  vlthin  tha  natwork. 

^  ianith  •  length  of  data  baing  transaittad. 

1.  option  data  -  options  raguastad  by  TCF  froa  thoaa  supportad  by 
natuork  protocol  including  at  laast  Mcurlty  Icballing.  (Tha 
Xntarnat  Protocol  supports  Mcurity  laballing,  source  routing, 
raturn  routing,  strasa  Idantificatlon,  and  tlaastaaping.) 

j.  data  -  prasant  whan  data  length  is  graatar  than  saro. 

8.2.2  Sarwlca  rasnonsa  oriaitiMS.  A  singU  Mrvica  response  priaitlaa, 
DBLim,  is  required  of  tha  nacwe^**daliMcy  sarrica. 

•.2.2.1  IKT  OilXm.  Tha  N8T  OCLXVEK  prialtiaa  contains  tha  data  pasMd 
by  a  source '73  inaBlT  SEND.  Jong  with  addressing,  quality  of  aarvica. 
aid  option  ifdomation.  *YCP  racaiwas  in  a  NITJ«tXveg  at  laast  tha  following 
inforaationi 


a.  source  address  •  address  of  Miding  TCP. 

dastinati^^n  address  -  address  of  tha  recipient  TCP. 

c.  protocol_^ identifier  assigned  to  TCP  as  supplied  by  tha 
MoSngtCP. 

d.  type  of  sarvica  iodicatOM  -  relative  transeission  quality 
aasociatad  with  unit  of  Jata. 

•  pracadanca  •  one  of  eight  levels  t  (PO.  PI.  P2.  P3.  P^»  P3. 

P8,  P7)  where  PO  <•  PI  <•  P2  <•  P3  <•  P4  <•  K  <•  W  P7. 

-  reliability  •  one  of  two  lavala:  (tO,  tl)  where  10  •  oonMl 
raliabiUty  aiC  tl  •  high  reliability. 

-  delay  -  one  of  two  lavalsi  (00,  01)  where  00  •  norasi 
delay  and  01  •  low  delay* 

•  throughput  -  one  of  two  levels:  (TO,  Tl)  where  TO  •  noraal 
throu^put  and  Tl  •  high  throughput. 
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••  dtf  length  -  Itogth  of  roctivod  data  (peaaibly  tore). 

f •  option  data  -  optiona  roquoatod  by  aourea  TCF  aa  aupportod  by 
tbt  oatwofk  including  at  loaat  aocurity  labtiling*  (Tht  Inttr- 
not  Protocol  aupporta  tacurity  laballing*  aourea  routing, 
raturn  rojtlngt  atraaa  idantification,  and  tiatataaping 
optiona*) 

i*  **  praaant  ahan  data  langth  ia  graatar  than  aaro* 

8.2*2. 1*1  lin  KELIVEK  trror  raporta*  In  addition,  a  NET^Daxm  aay  con¬ 
tain  arror  raporta  iroa  tha  nataork  protocol  aithtr  togathar  aith  paraaatara 
and  data  Uatad  abova,  or,  indapandantly  of  that  infotaation*  Tha  dataila 
of  tha  arror  raporta  art  nataotk  dapandant* 

8*3  Entandad  atata  aachint  apacification  of  aanricy  raauirad  froa  loaar 
laytr*  Tbt  cettndad  atata  aachint  in  thia  taction  difinaa  tha  hahaoior  of 
tht  tntirt  natuorh  protocol  aanriet  aachint  froa  tha  parapactiua  of  TCP* 

Thia  aarvica  aachint  ia  aodallad  aa  a  *blach  box*  uhoaa  intamal  aetiona  art 
hidden  froa  tht  TCPa  uaing  tha  nacwoih  pretocoI*a  aarricaa.  The  TCP-pair 
providaa  atiauli,  in  tha  fora  of  aarvica  raqueata,  and  racaivaa  tha  raaulting 
natuock  protocol  raaetiona,  in  tha  fora  of  aarvica  raaponaaa*  An  aba tract 
■achina  definition  ia  cenpoaad  of  a  aachitia  Identifier,  a  atata  dlagraa,  a 
atatt  vector,  a  oat  of  data  atrueturaa,  an  event  Uat,  and  an  avanta  and 
aciiona  corraapondanct* 

1*3.1  Hachina  inataotiation  idantifiar*  Each  upper  interface  atata  aachint 
ia  uniquely  i^ntiflai  by  the  iour  intaraction  prinitivi  paraaatatfi 

a*  aourea  addrati 
b*  daatinatiofi  addraaa 
e*  protocol 
d*  identifier 

One  atatt  aachint  inataoee  aaiata  for  tht  IKT^SEND  and  EET^CCttrEE  prlaitivat 
uhoit  paraaatara  carry  tht  aaae  valuta*  * 

diairaa.  Tht  upper  intarfaca  erart  aachint  haa  a  aingla  atata 
«#hieh  never  changaa*  ho  diagraa  ia  naadod* 

8.3*3  State  **acter*  Tht  upper  inttffact  atate  aachint  haa  a  ainglt  atatt 
vhich  never  changea*  ho  atatt  vector  ia  naaded* 

8.3.A  bate  atrueturaa*  For  clarity  ia  tha  avanta  and  aetiona  aaction, 
data  atructvrtii  aia  daciarad  for  the  interaction  prinitivaa  and  their  parana- 
tan.  A  aubttt  of  AAA  data  conatructa,  eaonon  to  noat  high  level  languagta, 
ia  vend,  hovtvtr,  a  data  ecructurt  nay  be  partially  typed  or  conplettly 
untyped  uhtrt  aptcific  lomata  or  data  typea  art  iopltntntation  dependent. 
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8.3.4.1  To  NET.  The  to_NET  structure  holds  the  interface  parameters  and 
data  assoaated  with  the  NET^SEND  primitive  speafied  above.  This  structure 
directly  corresponds  to  the  ToJJET  structure  declared  in  paragraph  9. 4. 4. A  of 
the  mechanism  definition.  The^to^NET  structure  is  declared  as: 

type  toJIET^type  la 
record 

■ource^addr 
desLinat ion^addr 
protocol 

typt^pfjitrvlce  is 
T^ord 

precedence 

reUability 

delay 

throughput 
end  record; 
identifier 
timejto^live 
don  t*fr  ague  nt 
lengTh 
data 
options 
end  record; 

8.3. 4.2  From  NET.  The  from_NET  structuie  holds  interface  parameters  and 
data  assoaated  vith  the  NET^oUlVER  priatlve.  as  specified  in  paragraph 
8.2.2.  This  structure  direcTly  corresponds  to  the  fromJIBT  structure  declared 
in  paragraph  9. 4, 4. 5  of  the  mechanism  definition.  The  fromJIET  structure  is 
declared  as: 

type  fromJJET^type  is 
record 

source^addr 

des  t i  nTt ion  ^add  r 

protocol 

type_of_setvlce  Is 
rsTorZ 

precedence 

reliability 

delay 

throughput 
end  record; 
length 
data 
options 
error 

end  record; 
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8*3,5  Event  list.  The  events  ere  drewn  from  the  Interection  primitives 
specified  in  Section  8*2,  An  event  is  composed  of  a  service  request  primitive 
and  an  abstract  timestamp  to  indicate  the  time  of  event  initiation.  The  event 
list  is  as  follows: 


a.  NET_SEND(  toJIET  )  at  time  t. 


b.  NULL  -  Although  no  service  request  is  issued  by  TCP,  certain  con¬ 
ditions  within  network  layer  or  lower  layers  produce  a  service 
response.  These  conditions  can  include  duplication  of  data  and 
subnet  errors. 


8.3.6  Events  and  actions.  The  following  section  defines  the  set  of  pos¬ 
sible  actions  elicited  by  each  event. 


8. 3. 6.1  EVENT  ■  NET  SEND  (to  NET)  at  time  t.  Actions: 


a.  NET_DELIVER  froo_NET  at  time  t+N  to  TCP  at  destination  toJIET. 
destinationjaddr  with  all  of  the  following  properties: 


-  The  time  elapsed  during  data  transmission  satisfies  the 
tlne-to-llve  limit,  l.e.  N  <■  to_NET.tlme^to_^llve. 


-  The  quality  of  data  transmission  is  at  least  equal  to  the 
relative  levels  specified  by  to^NET.type^of^servlce. 


•  if  (toJTCT.dont^fragment  •  TRUE)  then  network  Isyer  fragmen¬ 
tation  has  not  occurred  in  transit. 


-  if  (to^NET. opt ions  Includes  loose  source  routing)  then 
from  NET. data  has  visited  in  transit  st  least  the  gsteways 
named  by  the  source  provided  by  NET^SEND. 


-  if  (to  NET. opt ions  includes  strict  source  routing)  then 
froojCT.data  has  visited  in  trsnsit  only  the  gateways 
named  by  source  route  provided  by  NET^SEND. 


-  if  (to_KET. opt ions  includes  record  routing)  then  the  list 
of  node's  visited  in  transit  is  delivered  in  from  NET. 


-  if  (to^KET, opt ions  includes  security  labelling)  then  the 
securi*^  label  is  delivered  in  from^NET. 


-  if  (to_NET. opt  ions  includes  stream  identifier)  then  the 
stream'^idencif ier  is  delivered  in  from  NET. 


-  if  (toJlET. opt  ions  includes  internet  timestamp)  then  the 
internet  timestamp  is  delivered  in  from  NET. 
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OR, 

b*  NET^DELIVER  to  TCP  source  to_NET.source_*ddr  indicating  one  of 

the  following  error  conditions: 

-  destination  toJIET.destinationjiddr  unreachable 

-  protocol  to^NET. protocol  unreachable 

-  if  (toJJET.dont_fragnent  ■  TRUE)  then  fragmentation  needed 
but  prohibited  ~ 

-  if  (to_NET« opt ions  contains  any  option)  then  parameter  prob¬ 
lem  wi?h  option. 

OR, 

c.  no  action 

8. 3. 6.2  EVENT  ■  NULL.  Actions: 

a.  NET^DELIVER  to  TCP  at  source  to^NET.source^addr  it^icating  the 

following  error  condition:  *  " 

-  error  conditions  in  network  or  lower  layers 
OR. 

b.  NET_DELIVER  fromJJET  at  time  t^N  to  TCP  at  destination  toJIET. 

destinatioD^addr*" with  all  of  the  following  properties: 

-  The  time  elapsed  during  data  transmission  satisfies  the 
time-to-live  limit,  i.e*  N  <•  fromJTCT.tlme^to^live. 

-  The  quality  of  data  transmission  is  at  least  equal  to  the 
relative  levels  spr'*lfied  by  from^NET. type^of_servlce. 

-  if  (fromJ^ET.dont^fragomnt  •  TRUE)  then  network  layer  frag¬ 
mentation  has  not*~occurred  in  transit. 

-  if  (fromJfET. options  includes  loose  source  routir^)  then 
to^NET.data  has  visited  in  transit  at  least  the  gateways 
named  by  the  source  provided  by  NET^SEND. 

*  if  (fromJIET. options  includes  strict  source  routing)  then 
toJ^T.dsta  has  visited  in  transit  only  the  gatewaya  named 
by  source  route  provided  by  NET^SEND. 

-  if  (fromJiET. opt ions  includes  record  routing)  then  the  list 
of  node s"*vlsi ted  in  transit  is  delivered  in  toJIET. 

-  if  (fromJIET. opt  ions  includes  security  labelling)  then  the 
security  label  is  delivered  in  to^NET. 
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if  (froaM<lET.  opt  loos  Includes  stress  Identifier)  then  the 
stress  identifier  is  delivered  in  toJlET. 

if  (fros^NET* options  includes  internet  tisestssp)  then  tlw 
internet  tisests^)  is  delivered  in  to  NET. 
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9.  TCP  ENTITY  SPECIFICATION 

9.1  Gosl.  The  goal  of  this  section  Is  to  define  the  mechanisms  of  each 
TCP  entity  supporting  the  services  provided  by  the  TCP  service  machine.  The 
first  subsection  motivates  the  specific  mechanisms  chosen  and  discusses 

the  underlying  philosophy  of  those  choices.  The  second  subsection  defines 
the  format  and  use  of  the  TCP  segment  header  fields.  The  last  subsection 
specifies  an  extended  state  machine  representation  of  the  TCP  entity. 

9.2  Overview  of  TCP  mechanisms.  The  TCP  mechanisms  are  motivated  by  TCP 
services,  described  In  Section  5: 

a.  multiplexing  service 

b.  connection  management  services 

c.  data  transport  service 

d.  error  reporting  service 

9.2.1  Servlet  support.  Each  service  could  be  supported  by  any  of  several 
mechanisms.  The  selection  of  mechanisms  Is  guided  by  design  standards  Includ¬ 
ing  simplicity,  generality,  flexibility,  and  efficiency.  The  mechanism 
descriptions  Identify  the  service  or  services  supported  and  explain  how  the 
mechanisms  work.  This  overview  begins  with  an  Introduction  to  some  basic 
terminology  used  throughout  the  TCP  entity  mechanisms  discussions.  The 
mechanisms  present  In  a  TCP  entity  are: 

a.  flow  control  windows 

b.  duplicate  and  out-of-order  data  detection 

e.  positive  acknowledgments  with  retransmission 

d.  checksum 

e.  push 

f.  urgent 

g.  UliP  timeout 

h.  ULP^tlmcout  action 

1.  security  anT  precedence 

j.  security  ranges 

k.  multi-addressing 

l.  passive  and  active  open  raqi^ets 

m.  three-way  handshake  for  exchange 

n.  open  request  matching 

three-way  handshake  for  FIN  exchange 

p.  resets 

9.2.2  Background  and  terminology.  This  section  presents  the  terminology 
used  In  the  mechanism  descriptions.  The  concept  of  sequence  numbers  and 
sequence  space,  the  variables  maintained  In  a  state  vector  (defined  in  para¬ 
graph  9. 4. 4.1)  and  segment  header  fields  (defined  in  Section  9,3)  are  Intro¬ 
duced.  Also  presented  Is  a  list  of  the  states  within  the  TCP  state  machine 
(defined  in  Section  9.4). 

9. 2.2.1  Sequence  numbers.  A  fundamental  nxlon  In  the  design  of  the  TCP 
entity  Is  that  every  octet  of  data  sent  over  a  connection  has  a  sequence 
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number.  These  sequence  lumbers  are  used  by  several  mechanisms  (data  ordering, 
duplicate  detection,  positive  acknowledgment  with  retransmission,  and  flow 
control  windows)  to  provide  reliable,  ordered  data  transfer.  The  sequence 
number  carried  in  a  TCP  header  Is  a  four  octet  value  designating  the  sequence 
number  of  the  first  octet  of  data  In  the  segment.  Each  successive  data  octet 
Is  numbered  sequentially.  Thus,  each  segment  Is  bound  to  as  many  consecutive 
sequence  numbers  as  there  are  octets  of  data  in  the  segment. 

9.2.2. 1.1  Numbering  scheme.  The  numbering  scheme  is  extended  to  Include 
certain  control  Information  as  well.  This  is  achieved  by  implicitly  including 
some  control  flags  in  the  sequence  apace  so  they  can  be  reliably  transmitted 
without  confusion  (i.e. ,  one  and  only  one  copy  of  the  control  will  be  acted 
upon).  Control  Information  is  not  physically  carried  in  the  segment  data 
space.  Consequently,  we  must  adopt  rules  for  Implicitly  assigning  sequence 
numbers  to  control.  The  ’’SYN'*  and  "FIN**  flags  are  the  only  controls  requir¬ 
ing  this  protection.  These  controls  are  used  only  at  connection  opening  and 
closing.  For  sequence  number  purposes,  the  **SYN**  is  considered  to  occur 
before  the  first  actual  data  octet  of  the  segment  in  which  it  occurs.  Vhen 

a  "SYN"  is  present  then  SEG.SEQ  is  the  sequence  number  of  the  "SYN.**  The 
FIN  is  considered  to  occur  after  the  last  actual  data  octet  in  a  segment  in 
which  it  occurs.  The  segment  length  (LENCTTH)  includes  both  data  and  sequence 
space  occupying  controls.  It  is  essential  to  remember  that  the  actual  sequence 
number  space,  ranging  from  0  to  2**32->l ,  is  finite  though  very  large.  Because 
the  space  is  finite,  all  arithmetic  dealing  with  sequence  numbers  must  be 
performed  modulo  2**32.  This  unsigned  arithmetic  preserves  the  relationship 
of  sequence  lumbers  as  they  %rrap  around  from  2**32*1  to  0  again. 

9. 2 .2.2  Connection  sequence  variables.  To  maintain  a  connection,  a  TCP 
entity  records  and  updates  connection  status  information  in  a  state  vector. 
(This  is  also  called  a  Transmission  Control  Block,  or  TCB.)  Among  the  status 
i Information  stored  in  the  state  vector  are  sequence  variables  describing 
the  data  exchange  over  the  connection.  A  connection  carries  data  in  two 
directions,  and  so  each  TCP  entity  maintains  sequence  variaMes  for  both  the 
data  it  sends  and  the  data  it  receives. 

9. 2. 2. 2.1  Send  variables.  Send  variables  are  used  to  track  the  status  of 
the  send  data  stream  with  regard  to  acknowledgments,  urgent  data,  pufhed  data, 
window  size  and  position,  and  the  Initial  sequence  lumber.  This  list  is  a 
subset  of  the  complete  list  of  all  send  variables  appearing  in  the  state 
vector  definition,  paragraph  9. A. 3. 

a.  SEND^NEXT  *  send  next,  the  sequence  number  of  t)ie  next  octet 
of  d7ta  to  sent. 

b.  SENDJUNA  -  send  unacknowledged,  all  octets  up  to  but  not 
including  this  sequence  number  have  been  acknowledged. 

c.  SENDJtfNDW  -  send  window,  the  number  of  data  octets  currently 
allowed  to  be  sent  relative  to  SEKDJUKA. 

d.  SENDJURG  -  ser^  urgent  point,  the  sequence  number  of  the  last 
octet  of  urgent  data. 
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t.  SEND  PUSH  -  send  push  point,  the  sequence  number  of  the  lest 
octeT  of  pushed  decs. 

f.  SEND  LASTUPl  -  lest  window  updete  one,  the  sequence  lumber 
cerrTed  by  the  incoming  segment  used  for  lest  window  updete, 

g.  SEND  LASTUP2  -  lest  window  updete  two,  the  ecknowledgment  nicaber 
carried  by  the  incoming  segment  used  for  lest  window  updete. 

h.  SEND  ISN  -  initial  send  sequence  lumber,  the  sequence  mmber 
of  tlie  SYN  sent  on  this  connection. 


Theta  niiwi  corrtepond  to  the  eUte  vector  ele.ent»  defined  In  peregreph  9.4.3. 

9. 2. 2. 2. 2  Send  eequenee  cpaea.  If  the  epeee  of  tend  laquanee  nua^re  It 
pictured  «t  a  (uaber’une,  t^“folloiflng  dlegrt.  thowt  the  reietlonthlpi  twng 
some  of  the  verlebles  defined  above. 


I  2 

SEND  UNA 


SENOJIEXT 


SEND  UNA 
SEND  WNDW 


1  -  old  sequence  numbers  which  have  been  acknowledged 

2  -  sequence  numbers  of  sent  but  as  yet  unacknowledged  date 

3  -  sequence  numbers  allowed  for  new  data  transmission 

(l.e.  the  unused  send  window) 

4  •»  future  sequence  nui^rs  which  are  not  yet  allowed 

9.2. 2. 2. 3  Receive  verltblei.  The  receive  verlebUt  track  the  receive  date 
erree.  In  regard  to'TcknovladgMntt,  urgent  data,  poahed  data,  ulndou  alee 
aM  poaltlon,  and  initial  aequenca  twiiber.  Ihaae  varlablet  are  a  aubaet  of 
the  stite  vector  elements  defined  In  paragraph  9.4,3. 

a.  EECV  NEXT  -  receive  next,  the  sequence  timber  of  the  next 
data"octet  to  be  received. 

b.  tECV  WNDW  -  the  timber  of  data  octets  that  can  currently  be 
received  starting  from  RECV^NEXT. 

c.  NECV  URC  -  receive  urgent  point,  the  sequence  number  of  the 
last“octet  of  urgent  data. 

d.  RECV_PUSH  -  receive  push  point,  the  sequence  timber  of  the 
last~octet  of  pushed  data. 

e.  RECV  ISN  -  initial  receive  sequence  number,  the  sequence 
nuaiMr  of  the  SYN  received  from  the  remote  TCP. 
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9. 2. 2. 2.4  Rtcelve  fqutnct  tptct.  If  the  tpece  of  receive  sequence  itiabers 
le  pictured  es  •  nuiiber  llnc»  the  following  dlegren  shoifs  the  reUtlonshlps 
•aoi^  soae  of  the  variables  defined  above. 

1  2  3 


RECV  HEXT  RECV  NEXT 

*  +  RBCVWNDW 

1  -  old  sequence  nuebers  idilch  have  already  been  accepted 

2  -  sequence  nuabers  allowed  to  be  received 

(l.e.,  the  receive  window) 

3  -  future  sequence  niters  not  yet  allowed 

9.2. 2. 3  Current  segnant  variables.  TCP  entities  coanunleate  in  units  of 
exchaf«e  called  segMnts.  A  segnenc  is  sade  up  of  a  header,  containing 
addressing  and  control  infornatlon.  and  a  text  area,  containing  a  portion  of 
the  sand  or  receive  data  etreans.  A  formal  definition  of  the  segment  header 
format  appeeru  In  Paragraph  9.3.  The  following  header  fields  and  reUtad  values 
are  used  In  the  mechanism  descriptions. 

a.  SBG.SEQ  segment  sequence  lumber,  the  sequence  number  carried  in 
the  segment  haedar.  It  may  numter  the  first  octet  of  carried 
data,  nudbar  a  sequence  control  flag,  or  (in  an  empty  segment) 
indicate  the  next  octet  to  be  sent. 

b.  SBG.ACK-  segmint  acknowledgment  nudber.  the  acknowledgment 
from  the  sending  TCP.  That  is,  the  next  sequence  number 
expected  from  the  receiving  TCP. 

c.  SGC.UNDV  •  segment  window,  the  current  number  of  octets  that 
the  sailing  TCP  will  accept  as  counted  from  SEC.ACK. 

d.  SCC.URCPTk  *  segment  urgent  pointer,  the  number  of  date  octets 
remalnii«  before  the  end  of  the  urgent  data,  as  counted  from 
SEC.SCQ. 

e.  LENGTH  -  segment  length,  number  of  octets  of  header  and  text 
carried  In  the  segment.  This  value  is  supplied  as  a  service 

response  parameter. 

9.2. 2.4  Connection  states.  A  TCP  connection  progresses  through  three 
phases:  opening  (or  synchronlsetion),  maintenance,  end  closing.  The  three 
phases  are  broken  down  further  into  states  which  represent  significant  atages 
In  the  handshake  eedumlsas  of  connection  opening  and  closing.  These  states 
correspond  to  the  velues  assumed  by  the  primary  element  of  the  state  vector 
structure,  sv. state.  The  TCP  entity  states  ere: 
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a.  LISTEN  -  sfttr  s  pssslvt  opsn  request  froa  the  local  OLP, 
represents  vaitlng  for  a  connection  request  fro®  a  reaote  TCP 
Un  the  fora  of  a  SYN  segnsnt). 

b.  SWJ8ENT  -  after  an  active  open  request  froa  the  local  ULP 
and*havlng  sent  an  open  request  (1-e.,  s  SYN),  represents 
waltliv  for  a  aatchlng  connection  open  request  (l*e.,  another 
SYN)  froa  the  reaote  TCP. 

e.  SYN  RECEIVED  -  represents  vaitlng  for  a  eonflialng  connection 
request  acknovledgwnt  (l.e.,  the  ACK  of  the  SYN)  after  having 
both  received  and  sent  connection  requests. 

d.  ESTABLISHED  -  represents  an  open  connection  on  which  data  can 
be  pessed  between  DLPs  in  both  directions. 

a.  FIN  HAITI  -  after  a  close  service  request  froa  the  local  ULP, 
repTesents  valtlT«  for  either  e  close  request  (In  the  fora 
of  e  FIN  segasnt)  froa  the  reaote  TCP,  or  an  acknovledgnant 
of  the  close  request  already  sent  (l.e.,  en  ACK  of  the  FIN). 
Data  received  froa  reaote  TCP  Is  delivered  to  the  local  ULP. 

f.  FIN  HAITI  -  represents  waiting  for  a  connection  teial nation 
request  (l.e.,  i  FIN)  froa  the  reaote  TCP.  Data  recelvad 
froa  reaote  TCP  Is  delivered  to  the  local  ULP. 

g.  CLOSE  HAIT  -  represents  having  received  a  connection  close 
request  (l.e.,  a  FIN)  froa  the  reaote  TCP  and  vaitlng  for  a 
connection  close  request  froa  the  local  ULP.  Data  sent  by 
the  local  ULP  Is  sent  to  the  reaote  TCP. 

h.  UST  ACK  -  represents  having  both  sent  and  received  a  con- 
nectTon  close  request,  having  acknowledged  the  reaote  close 
request,  and  waiting  for  the  last  acknowledgaant  froa  the 
reaote  TCP. 

I.  CLOSING  -  represents  vaitlng  for  the  acknowledgaant  of  a  con¬ 
nection  close  request  (l.e.,  an  ACK  of  the  FIN)  froa  the  reaote 
TCP, 

J.  TIME  HAIT  -  represents  welting  for  enough  ties  to  pass  to 
ensuTe  the  reaote  TCP  has  received  the  acknowledgaant  of  Its 
connection  close  request. 

k.  CLOSED  -  represents  no  connection. 

The  full  definition  of  the  TCP  states,  events,  and  processing  appears  in 
Section  9.4. 

9.2.3  Flow  control  window.  TCP  provides  a  flow  control  aschanlse,  called 
a  window,  to  enable  a  receding  TCP  entity  to  govern  the  aaount  of  data 
trataaltted  by  a  set^lf^  TCP  entity.  A  window  Is  an  “absolute  flow  control 


73 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


MIL-STD-1778 
12  August  1983 


technique*  Absolute  flow  control  defines  an  interval  of  sequence  nunbers 
corresponding  to  the  aaount  of  data  an  entity  is  willing  to  accept.  This 
technique  prevents  aabiguity  introduced  by  duplicate  segaents  because  per- 
Biss ion  to  transmit  is  specified  as  a  specific  range  of  sequence  numbers 
rather  than  an  incremental  value.  The  receiving  TCP  maintains  the  amount  of 
data  allowed  for  acceptance  in  the  receive  variable  RECV^VNDW*  This  value 
is  bound  to  the  receive  sequence  space  leginnif^  at  RECVJIEXT,  the  next 
expected  data  octet*  A  TCP  entity  communicates  its  current  receive  window 
to  the  remote  TCP  by  piecing  the  window  in  each  outbound  segment  header  in 
the  following  manner*  The  window  field  of  the  segment  header*  SEC*VINX>OU* 
is  a  positive  integer  value  expressing  the  flitter  of  acceptable  data  octets* 
The  acknowledgmsnt  number  in  the  segment  header*  8EG*ACK*  associates  that 
quantity  to  the  receive  sequence  space*  Thus*  the  receive  window  starts  with 
SEG*ACK  end  continues  through  the  number  of  octets  indicated  by  SEG*WINDOU* 

As  each  incoming  segment  is  validated  by  sequence  nuhber  and  acknowledgment 
(Sections  9*2*3  and  9*2*4)*  the  TCP  entity  records  the  window  sise  in  the 
send  variable*  SENDJINDW* 

9 *2*3*1  Shrinking  windows*  A  TCP  entity  is  strongly  discouraged  from 
"shrinking**  its  receive  window*  A  window  is  said  to  shrink  when  a  TCP 
entity  advertises  a  Urge  window  and  subsequently  advertises  a  smaller  one 
without  having  accepted  the  difference  in  ^ta*  Such  behavior  complicates 
the  send  data  algorithms  of  the  peer  entity*  Tor  example*  a  sending  TCP 
may  set  upon  a  Urge  window  allocation  by  sending  all  of  the  advertised 
amount*  When  the  window  shrinks*  data  already  sent  becomes  outside  the 
window*  The  sender  must  either  set  back  the  send  variables  and  remove 
data  from  the  retransmission  queue  to  "laisend**  the  data,  or  else  ignore 
the  smaller  %rindow*  The  robustness  principle  mandates  that  although 
a  TCP  entity  does  not  shrink  its  own  receive  window*  it  will  be  prepared 
for  such  behavior  by  other  entities* 

9*2*3*2  Zero  windowa*  Windows  can  close,  that  is  become  sero  in  Ungth, 
when  a  receiving  TCP  Km  no  more  room  to  receive  data*  either  because 
the  UtP  has  stopped  accepting  or  because  system  resources  have  been 
temporarily  exhausted*  In  this  situation*  the  sending  TCP  normally  would 
not  send  data*  And*  if  no  data  is  generated  by  the  ether  ULP*  the  sendif^ 
entity  will  receive  no  new  window  updates*  Without  special  mechanisms, 
sero  windows  could  halt  data  transfer*  With  a  sero  send  window*  a  sendli^ 

TCP  must  be  prepared  to  accept  from  the  local  and  send  to  the  remote  TCP  at 
least  one  octet  of  new  data*  AUo,  a  sending  TCP  must  transmit  segments  at 
reguUr  intervaU  Into  the  sero  window  in  order  to  guarantee  that  the  re¬ 
opening  of  the  receive  window  will  be  reliably  reported*  The  recommended 
transmission  interval  in  this  situation  Is  two  minutes*  With  a  sero  receive 
window,  a  TCP  entity  receiving  a  segment  with  data  must  still  send  an  acknowl- 
•dg  Bsnt  showing  its  next  expected  sequence  (umber  and  current  window  even 
though  it  does  not  accept  the  data*  If  the  receiving  TCP  emits  an  empty  ACK 
segment  when  opening  its  receive  window,  it  may  teeume  receiving  data  more 
quickly*  Even  with  a  sero  receive  window*  a  TCP  must  process  the  ACK*  KST* 
and  URC  fields  of  all  acceptable  incoming  segments* 
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f  9. 2. 3. 3  Window  updstts  with  ons^vay  dsts  flow.  In  s  connection  with  dots 

1  flowlt^  priairily  in  one  direction,  the  window  informetion  will  be  carried 

in  segnents  narked  with  the  sane  sequence  nunber.  If  such  segnents  arrive 
I  out'*of'*order,  they  cannot  be  reordered*  This  situation  is  not  serious,  but 

!  it  does  Allow  the  window  infomation  to  occasionally  be  based  on  old  reports 

I  Iron  the  receiver*  A  strategy  to  avoid  this  problen  ie  to  check  both  the 

'  sequence  nunber  and  the  acknowledgnent  nunber  when  deciding  to  update  the 

send  window*  That  is,  use  the  witdow  infomation  fron  segnents  carrying 
either  a  higher  sequence  nunber  than  previously  seen,  or  the  sane  sequence 
nunber  aid  the  highest  acknowledgmnt  nudber*  The  highest  sequence  nunber 
of  an  incosdng  segnent  used  for  a  window  update  is  recorded  in  the  send 
variable  SEKDJLASTUPl ;  the  higheet  acknowledgntnt  lainber  in  SENDJ*ASTUP2  * 

9*2*3*4  Window  nawenent  suiiestions*  A  TCP  entity's  nethod  of  nsnaging 
its  window  has  significant  influence  on  perfomance*  The  following  sections 
disouse  certain  window  nsnsgensnt  policies  and  their  effects* 

9*2*3*A.l  Window  siie  vs*  actual  capacity*  In  general,  advertised  window 
slse  is  based  on  the  anount  of  available  receive  storage*  Although  indicating 
large  windows  encourages  transnissiona,  false  window  pronises  can  degrade  per- 
fomance*  If  the  window  is  Urgir  than  actual  storage  capacity,  wore  data  nay 
arrive  than  can  be  accepted*  The  SKcess  data  is  discarded,  causing  its  retrans* 
•iisien,  adding  unnecessarily  to  the  load  on  the  coMunications  systen  and  the 
sanding  TCP* 

9«2*3*4.2  Snail  windows*  Allocating  very  snail  windows  causes  data  to  be 
transnitted  in  aa^  saalirsegwsots*  letter  perfomance  nay  be  achieved  using 
fewer  large  segtMnts*  In  general,  if  both  sending  and  receiving  window  eanage^ 
went  algorithas  actively  atteept  to  eonbine  avail  window  allocations  into 
larger  windows,  the  tendency  toward  snail  segnsnts  can  be  avoided*  One 
suggestion  to  avoid  snail  windows  is  for  a  receiving  TCP  to  defer  updating 
a  window  wtll  an  allocation  is  at  least  X  percent  of  the  naxinun  allocation 
poaslbU  for  the  connection  (where  X  night  be  20  to  40)*  Thus,  the  TCP  could 
seid  an  ACX  when  a  segnent  arrives  (without  updating  the  window  Infomation), 
and  later  send  another  ACX  with  the  larger  window*  Another  suggestion  is 
for  the  seiklii^  TCP  to  avoid  sending  snail  segnsnts  by  waiting  until  the 
willow  is  *largs*  before  sending  data*  (Mote  that  acknowledgnents  should 
not  be  delayed  or  unneceesary  retransnissiona  will  result*) 

9*2*4  Ouplicact  and  out*of*order  data  detection*  The  network  protocol 
layer  nay  duplicate  or  change  the  order  of  segnents  subnitted  by  TCP  for 
transnlssion*  To  conpensate,  s  TCP  entity  uses  sequence  nui^rs  to  detect 
out*ef*erder  end  duplicate  segnsnts*  Duplicate  segnsnts  are  discarded* 

Segnsnts  arriving  out  of  order  nay,  depending  on  Inpleaentation  choices,  be 
either  discarded  or  saved  for  subsequent  processing*  The  duplicate  detection 
and  sequencing  algorithna  rely  on  the  unique  binding  of  segnent  data  to 
sequence  space*  The  algorithna  are  based  on  the  aasunption  that  all  2**32 
sequence  nunber  values  are  not  cycled  tt^ough  before  the  segnent  data  bound 
to  those  sequence  tubers  has  been  delivered  and  acknowledged  by  the  receiver 
ai^  all  duplicate  copies  of  the  segnents  have  “drained*  fron  the  internet* 
Vithout  such  an  assuaption,  two  distinct  TCP  segnents  could  conceivably  be 
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assigr.^c!  saoe  or  overlapping  sequence  wmbersi  causing  confusion  et  the 
rece;  vcr  <>•>  to  vhich  data  Is  new  end  which  Is  old*  A  sending  TCP  entity 
keeps  tr^*jK  c  the  sequence  lueber  of  the  next  data  octet  to  send  in  the 
variable  SlilNDjitXT*  In  each  outgoing  segaent»  the  entity  records  the 
sequence  amber  or  first  date  octet  in  the  eegoent  header  field,  SEG.SEQ, 
and  advances  SEKE^NlX.  by  the  total  amount  of  data  carried  in  the  segment* 

A  receiving  TCP  entity  keeps  track  of  the  sequence  amber  of  the  next  date 
octet  expected  In  the  variable  RECV^NEXT.  That  value  end  the  variable  RECV^ 
VKDW  represent  the  receive  wiikiow,  or  interval  of  acceptable  date  octets*  * 
This  interval  is  compared  against  incoming  segment  sequence  numbers  to 
determine  their  "acceptability* * 

9.2.4* 1  Incoming  end  uneecepteblc  segments*  An  incoming  segment  is  defined 
to  be  acceptable  if  any  crror*free  data  it  carries  falls  within  the  receive 
window.  If  the  segment  does  not  carry  data,  the  segment  sequence  oii^r  must 
fell  within  the  receive  window.  When  the  receive  window  is  sero,  a  segment 
is  acceptable  if  its  sequence  ojmber  equals  the  next  expected  sequence  wmber, 
RlCV^KEXT.  The  processing  of  unacceptable  segments  is  discussed  in  9*2*3* 

9.2*4. 1,1  "In  order"  date  acceptance*  The  control  information,  including 
valid  acknowledgment,  window  and  urgent  information,  must  be  used  free,  every 
accept nble  segment.  However,  the  policy  for  taking  (i*t*,  adding  to  the 
receive  queue)  the  data  of  an  acceptable  segment  can  be  approached  in  two 
ways*  The  first  approach  takes  only  in-order  date*  That  la,  only  data 
octets  with  sequence  numbers  starting  et  RECV.NEXT  and  continuing  through  to 
either  the  end  of  the  aegment  or  the  ami  of  the  receive  window  (whichever  is 
shorter)  are  taken*  The  data  octets  of  acceptable  aegmanta  with  aaqtianea 
numbers  starting  beyond  RECV.NEXT  are  not  taken*  This  *in-order*  approach 
allows  Immediate  acknowledgment  and  deliviry  to  the  ULP* 

9.2 *4 .1.2  "In  window"  data  acceptance*  The  second  approach,  called  “lir 
window"  data  acceptance,  tekea  any  data  falling  within  the  receive  window*  If 
the  date  it  not  conciguoui  with  previoualy  received  dite,  it  it  eeved  for  pro¬ 
cessing  until  tht  Intervening  data  arrives*  Thus,  eeknowledgmsnt  end  delivery 
will  be  deltyed  until  e  contiguous  interval  of  date  arrives* 

9.2.5  Positive  acknowledgment  with  retranamlaalon.  Another  mechanism 
compensating  for  network  protocol  bahavior  Is  positive  acknowledgment  with 
retrensmlsslon.  This  mechanism  replects  data  loat  or  damaged  in  transit 
through  Che  use  of  sequence  laii^ers  and  aeknowledgmanta*  The  baaic  atrategy 
with  PAR  la  for  a  tending  TCP  to  rttrcnamlt  t  etgment  at  timed  intervale  until 
a  positive  acknowledgment  Is  returned*  The  mtchsnlsm  requirements  for  segment 
retransmission,  acknowledgment  ecceptance,  transmlaaion  intervals,  and  sequence 
variable  manipulation  ere  described  below.  Tht  PAR  atrategy  requires  TCP  to 
keep  copies  of  sll  segments  In  order  on  t  "retransmission  queue."  As  each 
aegment  Is  sent,  a  aegment  copy  is  pieced  on  the  end  of  the  queue*  The  re¬ 
transmission  queue  holds  the  date  octets  whose  aequenet  numbtrs  begin  with 
SDiDJUKA.  tht  oldest  wacknowledfid  sequence  lumber,  and  ends  with  SEND  NEXT, 
the  next  octet  to  be  sent*  Vhen  ell  sent  data  has  been  acknowledged,  SIkOJUNA 
equals  SEKDJREXT,  end  tht  retransmission  queue  is  empty.  Vhen  date  la  placed 
on  tht  retrTntmlsslon  queue,  a  tleer  is  set  for  the  Interval  expected  to 
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tlapst  btfort  its  scknowlsgaant  rtturas.  Vhen  s  segmsnt  or  sn  scknowledgrvnc 
is  lost,  Che  recrsnsalsslon  clatr  will  expire  end  Che  TCP  will  recrsnsalt  che 
unacknowledged  daca.  If  che  original  segeenc  was  lose  or  discarded  due  co 
damage*  Che  recransalcced  segeenc  Is  accepced  as  che  original  ac  che  receiving 
TCP.  If  che  acknowledgeenc  was  lose.  Che  receiving  TCP  discards  che  recrans- 
■icced  segeenc  as  a  dupllcace.  but  resends  Ics  acknowledge nc« 

9.2.5.1  Acknowledgeenc  leaerstlon.  Every  TCP  segnenc.  axcludlng  an  Inlclal 
SYN  segeenc.  BUS c  carry  an  acknowledgeenc  Indicaclng  current  receive  variable 
Infoceaclon.  Acknowledgsenca  are  carried  in  che  TCP  segeenc  header  In  a 

four  occeC  field  deslgnaclng  che  sequence  nuaber  of  che  nexc  expecced  data 
octeC.  The  acknowledgeeenC  mechanise  Is  eumulaclve  so  chac  an  ACK  of  sequence 
miaber  X  It^lcaCes  chac  all  octets  up  Co  but  not  Including  X  have  been  received. 
Thus,  a  TCP  encicy  sees  che  ACX  field  of  each  outgoing  segeenc  Co  Che  value 
of  RECVJieXT.  Implicitly  stating  chac  IC  has  successfully  received  every 
data  oc?ec  up  to  Chat  sequence  number.  An  acknowledgeenc  does  not  gairancee 
Chat  data  has  been  delivered  Co  che  ULP.  but  only  that  che  destination  TCP 
has  taken  che  responslblllcy  co  do  so. 

9. 2.3.2  ACK  valldacloL.  Incoming  acknowledgments  are  compared  with  the 
aemi  variables  co  deCermlne  chelr  "accept ability.'"  An  "acctpcable  ACK"  Is 
one  for  which  Che  Inequality  telde:  SENDJINA  •<  SEC.ACK  -<  SEND  NEXT.  In 
other  words.  Che  acknowledgoeoc  refers  coTdata  equal  Co  or  beyond  chat  already 
acknowledged,  and  yet  does  not  exceed  che  sequence  (timber  of  data  yet  co  be 
sene.  U  SEC.ACK  <  SEND  UNA.  it  Is  an  old  ACK  and  Is  unacceptable.  If 
SEC.ACK  >  SENOJIEXT.  it  acknowledgis  data  not  yet  sent,  and  so  Is  unaccepCablt. 
When  an  accepclible  ACK  equals  SENDJJNA.  no  new  date  is  acknowledged  but  new 
wlMow  Inf  onset  ion  may  be  present.  When  an  acceptable  ACK  is  greater  than 
SENDJUNA,  ic  becomes  the  n«r  value  for  SEHO^UNA. 

9. 2. 5. 3  Ketra ns mission  queue  removals.  Acknowledgments  are  not  only  used 
CO  update  slKDj^U  and  SEND  OiU.  the7  are  also  processed  with  .espect  to 
the  retransmisTlon  queue.  wSen  an  ACK  arrives  fully  acknowledging  a  segment 
on  che  retransmission  queue,  the  segment  copy  is  removed  from  the  queue.  An 
ACK  Is  said  to  fully  acknowledge  a  segment  copy  on  the  retransmission  queue 
if  che  sum  of  the  segment  copy's  sequence  (timber  ai^  length  is  less  than  or 
equal  CO  the  acknowledgment  (ti^er  of  the  incoming  segment. 

9.2. 3.4  Retransmission  strategies.  A  TCP  implementation  may  employ  one 
of  several  retransmission  strategies. 

a.  flrst^onlv  retransmission  -  The  TCP  entity  maintains  one 
retransmission  timer  for  the  entire  queue.  When  the  retrans¬ 
mission  timer  expires,  it  sends  the  segment  (or  a  segment's 
worth  of  data)  at  the  front  of  tl4f  retransmission  queue  and 
resets  th«  timet. 

b.  Istch  retransmission  -  The  TCP  entity  maintains  one  retrans¬ 
mission  timer  (or  the  entire  queue.  When  tJte  r<f trsnsmlsslon 
timer  expires.  It  sends  all  the  segments  on  the  retransmission 
queue  and  resets  the  timtr. 
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c*  Individual  rstransai salon  -  Tht  TCP  tntity  Mlntalns  ons  tlatr 
for  sach  stgsttnt  on  tht  rstransvlsslon  quout.  As  tho  tlatrs 
txplro,  tht  stgatnts  art  rttransalttod  Individually  and 
tbalr  tlatrs  rtsat* 

A  brltf  discussion  of  rttransnlsslon  stratagy  tradt*offs  and  tholr  rtlatlonshlp 
to  tht  acctpttnct  policy  apptars  In  Apptndlx  A. 

9.2.5.5  Kttransalsslon  tltouts.  Tht  valut  of  tht  ratransalsslon  tlatr 
can  hsvt  a  iargt  effact  on  tht  ptrforatnca  of  both  tht  conntctlon  and 
tht  ntcvork,  A  tlatout  Inttrval  that  Is  too  short  rasults  in  unnaeassary 
ratransalsslons,  wasting  both  TCP  procasslng  tint  and  aatwork  rasoureas, 
vhllt  ont  that  Is  too  long  rasults  In  poor  throughput  and  poor  raaponaa 
tint  for  tha  ULP.  Idtally,  tht  rttrtnsnlsslon  Inttrval  should  aqual  txaetly 
the  tint  raqulrtd  for  a  stgatnt  to  travtrst  tht  network  to  Its  dtstlnatlon» 
be  processed,  and  Its  ACK  to  travtrst  tht  network  bade  to  tha  source*  Th^s 
sun  Is  called  the  kound  Trip  Tint  (ATT)  (sea  Apptndlx  8)*  Aaalistlcally, 
however,  this  valut  Is  rarely  known  or  constant*  Instead,  an  approxlnatlon 
of  this  sun  can  he  dynanlcally  conputad  during  tht  Ufttlna  of  a  eonnaetlon* 

9*2*8  Chtcksyi*  Tht  ehteksun  ntchanlsn  supports  arror*fraa  data  transfer 
servlet  by  enabling  detection  of  sagnents  danagtd  In  transit*  A  chacksun 
value  Is  conputtd  for  each  outbound  sagntnt  and  placed  In  tha  haadar's 
chacksun  field*  Slnllarly,  the  ehteksun  of  each  tncenlng  sagnsnt  la  conputad 
and  eonpartd  against  tha  valut  of  the  header's  ehteksun  field*  If  tha  values 
do  not  nateh,  tht  Inccnlng  sagntnt  Is  discarded  without  being  acknawltdisd* 
Hence,  a  danagad  sagntnt  apptars  the  sans  as  a  lost  sagnsnt  and  la  eonpan- 
sacnf  for  by  tht  PAt  ntchanlsn*  TCP  oats  a  slnpla  one's  canplantnt  algorltls 
d)ich  covers  tht  stgosnt  header,  tht  sagnent  data,  and  a  *psaudo  header** 

Tht  pseudo  header  Is  nadt  up  of  the  source  address,  the  destination  address, 
TCP's  protocol  Identifier,  and  tht  length  of  tha  T^  sagntot  (excluding  tha 
pseudo  header)*  iy  Including  the  extra  pseudo  header  Infornatlon  In  tht 
ehteksun,  TCP  protects  itself  fron  nlsdtllvtry  by  tha  network  protocol*  Tht 
ehteksun  algorlths  is  the  18*blt  one's  canplantnt  of  the  one's  conplanant  sun 
of  all  18*blt  words  tn  tha  pseudo  header,  sagnent  header,  and  the  sagnent 
text*  If  a  sagnent  contains  an  odd  minbtr  of  octets,  the  last  octet  is  padded 
on  the  right  with  stros  to  torn  a  18*hlt  word  for  ehteksun  purposes*  Uhllt 
canputlng  tht  ehteksun,  the  ehteksun  field  Itself  la  replaced  with  stros* 

9*2*7  Push*  Tht  data  that  flews  on  a  connect  ton  la  conceptually  a  siraan 
of  octets.  A  sending  TCP  is  allowed  to  collect  data  fron  tht  sending  Ul? 
and  to  stgntnt  and  send  the  date  tt  Its  own  convanltnct*  Tht  sending  UIP 
has  no  wt>  of  knowing  if  the  data  has  beta  sent  or  is  retained  by  the  locrl 
TCP  or  rtnott  TCP  while  waiting  for  a  nora  suitable  stgntnt  or  delivery 
site.  This  ntchanlsn  tnablti  a  ULP  to  push  data  through  both  the  local  and 
rtnott  TCP  entities*  When  *push*  flag  is  set  In  a  SCUD  request,  the  sending 
TCP  stgntnis  and  tends  all  Internally  einred  dtet  within  flew  control  Units. 
Upon  receipt  of  t  puthed  segnent,  the  receiving  TCP  nutt  pronpily  deliver 
thr  puehed  deta  tu  t!«e  receiving  ULP*  fucceteive  puehes  ney  not  be  preaerved 
because  two  or  nore  unite  of  puehed  dete  ney  be  joined  into  e  sifH(le  pushed 
unit  by  either  the  tending  or  receiving  TCP*  Pushes  sre  not  vistble  to  tht 
receiving  utP  end  ere  not  intended  to  serve  et  e  record  boundary  narkar* 

78 


1-238 


MILIT.\RY  STANDARDS:  TCP 


MIL-STD  1778 


MIL-STD-1778 
12  August  1983 


9.2.8  Urgent.  TCP  provides  «  neans  to  communicate  to  a  receiving  ULP 
that  some  point  in  the  upcoming  dati  stream  has  been  marked  urgent  by  the 
sending  ULP,  Also,  the  receiving  TCP  can  Indicate  when  all  the  currently 
known  urgent  data  has  been  delivered  to  the  receiving  ULP.  The  objective 
of  the  TCP  urgent  mechanism  is  to  enable  the  sending  ULP  to  stimulate  the 
receiving  ULP  to  accept  some  urgent  data.  TCP  does  not  define  what  the  ULP 
is  required  to  do  with  the  urgent  state  information,  but  the  general  notion 
is  that  the  receiving  ULP  will  take  action  to  process  the  Intervening  data 
quickly.  The  urgent  mechanism  permits  a  point  In  the  data  stream  to  be 
designated  as  the  end  of  urgent  information.  Whenever  this  point  is  in 
advance  of  the  variable  RECVJ^EXT  at  the  receiving  TCP,  that  TCP  must  tell 
the  UIP  to  go  into  "urgent  m7de;"  when  the  receive  sequence  number  catches 

up  to  the  urgent  pointer,  the  TCP  oust  tell  the  ULP  to  go  into  "normal  mode." 
If  the  point  is  updated  while  the  ULP  is  in  urgent  mode,  the  update  will  be 
invisible  to  the  ULP.  Note  that  urgent  data  cannot  be  delivered  together 
with  any  nonrurgent  data  that  may  follow.  The  mechanism  employs  an  urgent 
field  which  is  carried  in  all  segments  transmitted.  The  URG  control  flag 
Indicates  that  the  urgent  field  is  meaningful.  The  urgent  field  must  be 
added  to  the  segment  sequence  number  to  yield  the  sequence  number  of  the 
last  octet  of  urgent  data.  The  absence  of  this  flag  indicates  that  there 
is  no  urgent  data  outstanding.  To  send  an  urgent  Indication  the  ULP  must 
also  send  at  least  one  data  octet.  If  the  sending  ULP  also  indicates  a 
push,  timely  delivery  of  the  urgent  information  to  the  destination  process 
Is  enhanced.  When  an  urgent  indication  spears  in  a  Send  service  request 
but  the  sand  window  does  not  allow  data  to  be  sent  immediately,  the  TCP 
should  senl  an  empty  ACK  segiKnt  with  the  new  urgent  information. 

9.2.9  ULP  timeout  and  ULP  timeout  action.  The  timeout  allo%rs  a  ULP  to 
set  up  a  timeout  for  all  data  submitted  to  the  TCP  entity.  If  some  data  is 
not  successfully  delivered  to  the  destination  within  the  timeout  period,  the 
state  of  UlP^timeou traction  is  checked.  If  ULP^tlmeou traction  is  1,  the  TCP 
entity  will  Terminate  the  connection.  If  it  is  0,  the  TCP  entity  informs 
the  ULP  that  a  timeout  has  occurred,  and  then  resets  the  timer.  The  timeout 
appears  as  an  optional  parameter  in  the  open  request  and  the  send  request. 
Upon  receiving  either  an  active  open  request,  or  a  SYN  segment  after  a 
passive  request,  the  TCP  entity  must  maintain  a  timer  set  f^r  the  Interval 
specified  by  the  ULP.  As  acknowledgments  arrive  from  the  remote  TCP,  the 
timer  is  cancelled  and  set  again  for  the  timeout  Interval.  4s  parameters 

of  the  SEND  request,  timeout  and  timeou traction  can  change  during  connection 
lifetime.  If  the  timeout  is  reduced  bellw  the  age  of  data  waiting  to  be 
acknowledged,  the  event  dictated  by  ULP^timeou traction  will  occur.  The 
implementor  nay  choose  to  allow  additional  options  when  informing  the  ULP 
in  case  of  a  timeout;  for  example,  Infoniing  the  ULP  only  on  the  first 
timijout. 


9.2.10  Security.  TCP  makes  use  of  the  Internet  Protocol  (IP)  options  to 
provide  security  and  precedence  on  a  per  connection  basis.  The  security 
ani  precedence  parameters  used  in  TCP  ere  those  defined  In  IP.  Throughout 
this  TCP  epeciflcetlon  the  term  "eecurity  information"  Indlcatea  the  security 
parameters  used  in  IP,  including  security  level,  compartment,  user  group, 
and  handling  restrictions.  In  order  for  a  TCP  connection  to  be  estaoUshed, 
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the  nodules  at  each  end  of  the  connection  nust  agree  on  the  security  infor¬ 
mation  and  precedence  to  be  associated  with  the  connection.  During  a  passive 
open,  the  option  exists  to  pass  a  security  structure  of  conpartneVits»  user 
groups,  and  handling  restrictions  valid  for  that  connection.  The  inplenenta- 
tion  of  this  data  type  is  dependent  on  local  security  policy.  For  each 
permutation,  there  exists  a  security-level  range  composed  of  a  high  and  lew 
link.  If  only  one  security  level  is  required,  the  high  and  low  limits  would 
be  the  same.  If  no  security  structure  is  passed,  the  inpleaentation  dependent 
default  structure  is  used.  When  an  active  open  request  contains  security 
parameters  within  the  ranges  specified  by  the  passive  open,  a  connection  is 
established.  Those  exact  parameters  are  then  used  for  the  duration  of  the 
connection. 

9.2.11  Precedence  level.  The  precedence  level  of  the  connection  is  negoti¬ 
ated  through  the  exchange  of  lower  bounds  by  each  end  during  connection 
opening.  The  higher  of  the  two  values  is  assigned  to  the  connection.  If  it 
is  impossible  for  the  end  with  the  lower  precedence  to  raise  its  level  to 

the  higher,  or  to  get  the  security  information  to  natch  the  connection 
must  be  rejected.  The  inability  to  match  security  information  or  precedence 
levels  is  indicated  by  the  receipt  of  segments  after  the  connection  opening 
with  the  non-matching  information.  The  connection  is  then  rejected  by  sending 
a  reset.  In  addition  to  sending  a  reset,  the  connection  attempt  with  mis¬ 
matched  security  information  may  be  reported  or  recorded  in  accordance  with 
local  stardard  operating  procedures.  After  the  connection  is  established, 
the  TCP  modules  must  mark  outgoing  segments  with  the  agreed  security  informa¬ 
tion  and  precedence  level.  Any  incoming  segment  with  security  information 
or  precedence  level  not  exactly  matching  that  of  the  connection  causes  the 
termination  of  the  connection.  A  reset  l«i  sent  to  the  remote  TCP  and  the 
local  DIP  is  Informed  of  the  error. 

9.2.12  Multiplexing.  TCP  provides  a  aet  of  addresses,  called  port  identi¬ 

fiers,  to  allow  for  many  ULPs  within  a  single  host  to  use  TCP  communication 
facilities  simultaneously  and  to  identify  the  separate  data  streams  that  a 
ULP  may  request.  Port  identifiers  are  selected  Independently  by  each  TCP 
entity.  To  provide  unique  addresses,  TCP  concatenates  an  Internet^sddress^ 
identifying  its  Internet  location  to  a  port  Identifier  creating  a  “iocket.** 
Thus,  sockets  are  unique  throughout  the  Internetwork  and  s  pair  of  sockets 
can  uniquely  Identify  each  TCP  connection.  A  socket  may  participate  in  many 
connections  to  different  foreign  sockets.  TCPa  are  free  to  asaociate  porta 
with  processes  however  they  choose.  However,  several  concepts  art 

necessary  in  any  implementation.  There  are  “well-known**  sockets  which  s 

TCP  entity  sssoclstes  only  with  the  “approprlste**  ULP  by  some  means.  Well- 
known  sockets  are  a  convenient  mechaniam  for  a  priori  asaociatlng  a  socket 
address  with  a  standard  service.  For  instance,  the  'Telnet-Server*  process 
Is  permanently  assigned  to  e  particular  socket,  and  other  sockets  are  reserved 
for  File  Transfer,  Remote  Job  Entry,  Text  Generator,  Echoer,  and  Sink  processes 
(the  Last  three  being  for  test  purposes).  A  socket  address  might  be  reserved 
for  access  to  a  “Look-Up"  service  which  would  return  the  specific  socket  at 
which  «  newly  treated  service  would  be  provided  •  The  concept  of  s  well— 
socket  Is  part  of  the  TCP  specification,  but  the  assignment  of  sockets  to 
services  is  outside  this  specification. 
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9,2.13  Connection  opening  ncchanisas.  Several  aechanlsiia  are  used  to 
establish  connections  between  two  TCP  entities.  These  aechanlsms,  including 
open  requests,  sequence  nuaber  synchronixatlon,  and  initial  sequence  number 
generation,  are  discussed  below. 

9.2.13.1  Connection  open  requests.  TCP  provides  a  UIP  with  two  ways  of 
opening  a  connection,  called  passive  open  requests  and  active  open  requests. 

The  open  requests  have  certain  paraaeters  Including  the  local  socket  and 
foreign  socket  nataing  the  connection. 

9.2.13.1.1  Passive  open  request.  With  a  passive  open  request,  the  TCP 
entity  assigns  a  state  vector  for  the  connection  variables,  returns  a 
local  connection  naae,  and  be  coses  “receptive**  to  connections  with  other 
ULPs.  The  foreign  socket  paraaeter  in  a  passive  open  request  say  be  either 
fully  specified  or  unspecified.  That  is,  when  the  foreign  socket  parameter 
is  set  to  a  specific  socket  value,  only  the  ULP  %rith  that  socket  identifier 
can  be  connected,  tf  the  foreign  socket  is  unspecified  (denoted  by  all 
xeros)  any  UCP  can  be  connected.  Such  unspecified  foreign  sockets  are 
allowed  only  on  passive  open  requests.  A  service  ULP  that  wished  to  provide 
services  for  unknown  other  ULPs  would  issue  an  unspecifed  passive  open 
request,  supplying  its  own  well-known  socket  for  the  local  socket. 

9.2. 13.1.2  Active  open  request.  With  an  active  open  request,  the  TCP 
entity  not  only  assigns  a  state  vector  and  a  local  connection  naae,  but  also 
actively  initiates  the  connection  by  sending  a  STN  segment.  A  connection 

is  inltisted  by  the  reidexvous  of  an  arriving  segment  containing  a  SYN  and  a 
watting  state  vector.  The  matching  of  local  and  foreign  sockets  determines 
when  a  connection  has  haen  Initiated.  There  are  two  principal  cases  for 
watching  the  sockets  /n  the  local  open  requests  to  the  foreign  sockets  in 
arrivii^  SYN  segasnta.  In  the  first  case,  the  local  open  has  fully  specified 
the  foreign  socket  so  the  watch  aust  be  exact.  In  the  second  case,  the 
local  passive  open  has  left  the  foreign  socket  unspecified  so  any  foreign 
socket  U  acceptable  as  long  as  the  local  sockets  watch.  Other  possibilities, 
left  up  to  the  iwplewentor,  include  partially  restricted  matches.  If  there 
are  several  pending  open  requests  with  the  same  local  socket,  a  foreign 
active  open  will  be  watched  to  a  fully  specified  open,  If  one  exists,  before 
selecting  an  unspecified  passive  open. 

9.2.13.2  Three-way  handshake.  The  “three-way  handshake’  is  the  mechanism 
used  to  establish  a  connection.  This  procedure  normally  Is  Initiated  by  one 
TCP  ar^  responded  to  by  another  TCP.  The  proceoure  also  works  if  two  TCPs 
simultaneously  Initiate  the  procedure.  When  two  ULPs  wish  to  communicate, 
they  issue  open  requests  as  described  above,  instructing  their  TCPs  to 
initialise  and  synchronise  the  mechanism  Information  on  each  side.  However, 
the  potentially  unreliable  network  layer  can  complicate  the  process  of 
synchronisation.  Delayed  or  duplicate  segments  from  previous  connection 
attempts  wight  be  wistAen  for  new  ones.  A  handshake  procedure  with  clock 
based  sequence  numbers  Is  used  In  connection  opening  to  reduce  the  posslbllitv 
of  such  false  connections. 
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9.2. 13.2.1  Simplest  handshake.  In  the  simplest  handshake  between  an 
active  open  request  and  a  passive  oper.  request,  the  TCP  pair  synchronizes 
sequence  lumbers  by  exchanging  three  segments.  The  actively  opened  TCP 
entity  emits  a  segment  marked  with  a  synchronize  control  flag,  called  a 
"SYN**  segment,  which  is  matched  at  the  receiving  TCP  eutlty  to  the  passive 
open  request.  The  receiving  TCP  entity  emits  its  own  IH'N  also  carrying  an 
acknowledgment  of  the  first  SYN.  That  segment  Is  responded  to  with  an 
acknowledgment.  Thus,  a  three  segment  exchange  establishes  the  connection. 
When  simultaneous  active  open  requests  initiate  the  connection  each  TCP 
receives  a  SYN  segn^nt  which  carries  no  acknowledgment  after  it  has  sent  a 
SYN.  Each  respond  with  an  acknowledging  segment  and  a  connection  is 
established  In  four  exchanges.  Of  course,  the  arrival  of  an  old  duplicate 
SYN  segment  can  potentially  make  It  appear,  to  the  recipient,  that  a 
simultaneous  connection  Initiation  is  in  progress.  Proper  use  of  '’reset" 
segments  will  avoid  ambiguity  In  these  cases. 

9.2.13.2.2  Examples  of  connection  Initiations.  Several  examples  of  con¬ 
nection  initiation  follow.  Although  these  examples  do  not  show  connection 
synchronization  using  data  carrying  segments,  this  Is  perfectly  lef^ltimate, 
so  long  as  the  receiving  TCP  does  not  deliver  the  data  to  the  ULP  until  it 
Is  clear  the  data  Is  valid  (l.e.,  the  data  must  be  buffered  at  the  receiver 
until  the  connection  reaches  the  ESTABLISH^)  state).  The  three-way  handshake 
reduces  the  possibility  of  false  connections.  It  is  the  Implementation  of 

a  trade-off  between  memory  at^  messages  to  provide  information  for  this 
checking.  The  simplest  three-way  handshake  Is  shown  In  the  scenario  In 
Section  4.  Other  examples  are  shown  below.  The  figures  should  be  interpreted 
in  the  following  vsy.  Each  line  is  numbered  for  reference  purposest  Right 
arrows  (— >)  Indicate  departure  of  a  TCP  aegment  from  TCP  A  to  TCP  6,  or 
arrival  of  a  segmsnt  at  B  from  A.  Left  arrows  (<— )  indicate  the  reverset 
Ellipsis  (...)  indicates  a  segment  which  is  still  In  the  network  (dtlsytd). 

An  "XXX"  indicates  a  segment  which  Is  lost  or  rejected.  Comments  appear  In 
parentheses.  TCP  states  rtpresent  the  state  AFTER  the  departure  or  arrival 
of  the  segment  (whose  contents  are  shown  in  the  canter  of  each  Una).  Segment 
contents  are  shown  in  abbreviated  form,  with  sequence  number,  control  flags, 
and  ACK  field.  Other  fields  such  as  window,  addresses,  lengths,  end  text 
have  been  left  out  in  the  intereit  of  clarity. 

9.2.13.2.2.1  Simultaneous  connection  initiation.  Simultaneous  initiation 
la  only  slightly  more  complex  than  a  three-way  handihake.  Each  TCP  eyelet 
from  aoSED  to  SYN-SENT  to  SYN-RECEIVED  to  ESTABLISHED.  The  principal  reason 
for  the  three-way  handihake  la  to  prevent  old  duplicate  connection  Inltletloos 
from  causing  confusion.  To  deal  with  this,  a  ipeclal  control  mtiiage,  reset, 
is  used.  If  the  rtceivii^  TCP  is  in  a  nonsynchrooited  state  (l.e.,  SYH-SEKT, 
SYN-RECEIVED),  it  returni  to  LISTEN  on  receiving  an  acceptable  reset.  If 
the  TCP  ii  in  one  of  the  synchronized  states  (ESTABLISHED,  FIN-4jAlT-i , 
FIN-WAlT-2.  aOSE-WAIT,  aoSlNC,  UST-ACK,  TIME-WAIT),  it  aborts  the  con¬ 
nection  and  Informs  its  UIP.  This  case  it  dlacuiied  under  "half-open" 
connect  ions  below. 
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1. 

2. 

3. 

4. 

5. 

6. 
7. 


TCP  A 
CLOSED 

SYN-SENT  — >  <SEQ-100><CTL-SYN> 

SYN-RECEIVED  <—  <SEQ«300><CTL-SYN> 
<SEQ-100><CTL-SYN> 

SYN-RECEIVED  — >  <SEQ-100><ACK-301XCTL-SYN,ACK> 
ESTABLISHED  <—  <SEQ«300><ACK«10l><CTL-SYN,ACK> 
<SEQ-101XACK-301XCTL-ACK> 


TCP  B 
aOSED 

•  •  • 

<—  SYN-SENT 
— >  SYN-RECEIVED 

•  •  • 

<—  SYN-RECEIVED 
— >  ESTABLISHED 


9.2, 13.2.2.2  Old  duplicstc  SYN  d«ttctlon.  At  a  simple  example  of  recovery 
from  old  duplicates,  cot^lder  the  following  figure.  At  line  3,  an  old  dupli¬ 
cate  SYN  arrives  at  TCP  B.  TCP  B  cannot  tell  that  this  is  an  old  duplicate, 
so  it  responds  normally  Cline  4).  TCP  A  detects  that  the  ACK  field  is  incor¬ 
rect  and  returns  a  RST  (reset)  with  its  SEQ  field  selected  to  make  the  segment 
believable.  TCP  B,  on  receiving  the  RST,  returns  to  the  LISTEN  state.  When 
the  original  SYN  finally  arrives  at  line  6,  the  synchronisation  proceeds 
normally.  If  the  SYN  at  line  6  had  arrived  before  the  RST,  a  more  complex 
exchange  might  have  occurred  with  RSTs  sent  in  both  directions. 


TCP  A  TCP  B 

1.  aOSED  LISTEN 

2.  SYN-SENT  — >  <SEQ-I00XCTL-SYN> 

3.  (duplicate)  ...  <SEQ-90><CTL-SYN>  — >  SYN-RECEIVED 

4.  SYN-SENT  <—  <SEQ-300><ACIC"91XCTL*SYN,ACK>  <—  SYN-RECEIVED 

5.  SYN-SENT  — >  <SEQ-9l><CTL-RST>  — >  LISTEN 

6.  ...  <SEQ»100XCTL»SYN>  — >  SYN-RECEIVED 

7.  SYN-SENT  <—  <SEQ-400><ACR-101><CTL-SYN  ,ACK>  <—  SYN-RECEIVED 

B.  ESTABLISHED  — >  <SEQ»101XACK-401XCTL»ACK>  — >  ESTABLISHED 

9.2.13.2.2.3  Half-open  connections.  An  established  connection  Is  said 
to  be  “half-open^ If  one  of  the  TCPs  has  closed  or  aborted  the  connection 
at  its  end  without  the  knowledge  of  the  other,  or  If  the  two  ends  of  the 
connection  have  become  desynchronized  owing  to  a  crash  chat  resulted  In 
loss  of  memory.  Such  connections  will  automat Ically  become  reset  If  an 
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attempt  Is  made  to  send  data  in  either  direction.  However,  half*open  con¬ 
nections  are  expected  to  be  unusual,  and  the  recovery  procedure  is  somewhat 
involved.  If  at  site  A  the  connection  no  longer  exists,  then  an  attempt  by 
the  ULP  at  site  B  to  send  any  data  on  it  i^ill  result  in  the  site  B  TCP 
receiving  a  reset  control  message.  Such  a  message  indicates  to  the  site  B 
TCP  that  something  is  wrong,  and  it  is  expected  to  abort  the  connection. 

Assume  that  two  ULPs  A  and  B  are  communicating  with  one  another  when  a 
crash  occurs  causing  loss  of  memory  to  A*s  TCP.  Depending  on  the  operating 
system  supporting  ULP  A's  TCP,  it  is  likely  that  some  error  recovery  mechanism 
exists.  When  the  TCP  is  up  again,  ULP  A  is  likely  to  start  again  from  the 
beginning  or  from  a  recovery  point.  As  a  result,  ULP  A  will  probably  try 
to  OPEN  the  connection  again  or  try  to  SEND  on  the  connection  it  believes 
open.  In  the  latter  case,  it  receives  the  error  message  "connection  not 
open"  from  the  local  (ULP  A*s)  TCP.  In  an  attempt  to  establish  the  con¬ 
nection,  ULP  A*s  TCP  will  send  a  segment  containing  SYN.  This  scenario 
leads  to  the  example  shown  in  figure  10.  After  TCP  A  crashes,  the  ULP 
attempts  to  open  the  connection  again.  TCP  B,  in  the  meantime,  thinks  the 
connection  is  open.  When  the  SYN  arrives  at  line  3,  TCP  B,  being  in  a 

synchronized  statei  sees  the  incoming  segment  outside  the  window  and  responds 
with  an  acknowledgment  indicating  what  sequence  it  next  expects  to  hear  (ACK 
100).  TCP  A  sees  that  this  segment  does  not  acknowledge  anything  it  sent  and, 
being  unsyncluronized,  sends  a  reset  (RST)  because  it  has  detected  a  half-open 
connection.  TCP  B  aborts  at  line  5.  TCP  A  will  contime  to  try  to  establish 
the  connection;  the  problem  is  now  reduced  to  the  basic  three-way  handshake* 


TCP  A 

TCP  B 

1. 

(CRASH) 

(tend  300, receive  100) 

2. 

CLOSED 

ESTABLISHES) 

3. 

SYN-SENT  — > 

<SE0-4O0><CTL-SYN> 

->  (??) 

4. 

(.M)  <— 

<SEQ«jOO><ACK-IUO><CTL-ACK> 

<—  ESTABLISHED 

3. 

SYN-SENT  — > 

<SEQ«*100><CTL-RST> 

— >  (Abort!!) 

6. 

SYN-SENT 

aOSEO 

7.  SYN-SENT  — >  <SEQ-400><CTL»SYN>  — > 


9.2.13.2.2.4  Alternate  case  1.  An  interestii^  alternative  case  occurs 
when  TCP  A  crashes  and  TCP  B  tries  to  send  data  on  what  It  thinks  Is  a  syn¬ 
chronized  connection.  This  Is  Illustrated  In  the  next  figure.  In  this 
cate,  the  data  arriving  at  TCP  A  from  TCP  B  (line  2)  la  unacceptable  because 
no  such  connection  exists,  so  TCP  A  sends  a  RST.  The  RST  is  acceptable  so 
TCP  B  processes  It  and  aborts  the  connection. 
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TCP  A  TCP  B 

1.  (CRASH)  (send  300»recelve  100) 

2.  (??)  <—  <SEQ-300><ACK-100><DATA-10><CTL^CK>  <—  ESTABLISHED 

3.  — >  <SBQ-100><CTL-RST>  — >  (ABORTIl) 


9.2.13.2.2.5  Alternate  esse  2»  In  the  follovlng  figure,  TCPs  A  and  B 
with  passive  opens  are  waiting  for  STNs*  An  old  duplicate  arriving  at  TCP  B 
(line  2)  stirs  B  Into  action.  A  SYN^ACK  la  returned  (line  3)  and  causes  TCP  A 
to  generate  a  RST  (the  ACK  In  line  3  Is  not  acceptable).  TCP  B  accepts  the 
reset  and  returns  to  Its  passive  LISTEN  state. 


TCP  A 

1.  LISTEN 

2.  ...  <SEQ-Z><CTL-SYN> 

3.  (??)<—  <SEQ-X><ACK-2'H><CTL-SYN,ACK> 

4.  — >  <SEQ-2+lXCTL»RST> 


TCP  B 
LISTEN 

— >  SYN-RECEIVED 
<—  SYN-RECEIVED 
— >  (return  to  LISTEN!) 


5.  LISTEN 


LISTEN 


A  variety  of  other  cases  Is  possible,  all  of  which  are  accounted  for  by  the 
reset  generation  and  processing. 

9.2.13.3  Initial  sequence  number  selection.  TCP  leposes  no  restrictions 
on  a  particular  connection  being  used  over  at^  over  again.  A  connection 
Is  only  naaed  by  a  pair  of  sockets.  New  Instances  of  a  connection  will  be 
referred  to  as  Incarnations  of  the  connection.  The  problee  that  arises 
Is  how  to  Identify  duplicate  segtaants  froa  previous  Incarnations  of  the 
connection.  This  probltr  becoacs  apparent  If  the  connection  Is  being 
opened  and  closed  In  quick  succession,  or  If  the  connection  breaks  with  loss 
of  aaaory  and  la  then  reestablished.  To  avoid  confusion,  segaentt  froa  one 
Incarnation  of  a  connection  auat  not  be  used  while  the  saae  sequence  miabers 
aay  still  be  present  In  the  network  froa  an  earlier  Incarnetlon.  This  aust 
be  assured,  even  If  a  TCP  crashes  and  loses  all  knowledge  of  the  sequence 
nuabers  It  has  been  using.  Thus,  a  clock-baaed  Initial  sequence  nuaber 
generation  procedure  has  been  defined. 


9.2.13.4  ISN  generator.  Uhen  new  connections  are  created,  an  initial 
sequence  maber  (ISN)  generator  Is  eaployed  which  selects  a  new  32-blt  ISN. 
The  generator  Is  bound  to  a  (possibly  fictitious)  32-blt  clock  whose  low 
order  bit  Is  Increaented  roughly  evary  4  alcroseconda.  Thus,  the  ISN 
cycles  approalaacely  every  4.55  hours.  Asaualng  aegaenta  will  stay  in  the 
network  no  aore  than  the  Haxiaua  Segaent  llfetlae  (NSL)  and  that  the  MSL  is 
less  than  4.SS  hours,  ISNs  will  be  unique. 
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9*2 .14  Connection  closing  lynchrotiltation.  Connection  closing  Is  hendled 
similarly  to  connection  establishment.  The  following  mechanism,  Including 
close  request  and  fin  exchange,  support  the  reliable  data  transport  and 
graceful  connection  closing  services. 

9.2.14.1  Close  requests.  A  close  request  Indicates  that  the  local  ULP 

has  completed  Its  data  transfer  over  the  connection.  A  ULP  may  close  a 

connection  at  any  time  on  Its  own  Initiative.  Closing  connections  Is  Inteikled 
to  be  a  graceful  operation  In  the  sense  that  outrtandlng  send  requests  will 

be  transmitted  (and  retransmitted),  as  flow  control  peimlts,  until  all  have 
been  serviced.  Thus,  It  should  be  acceptable  to  make  several  send  requests, 
followed  by  a  close  request,  and  expect  all  the  data  to  be  sent  to  the 
destination  ULP.  It  should  also  be  clear  that  ULPs  should  continue  to  accept 
data  on  closing  connections,  since  the  other  ULP  may  be  trying  to  transmit 
the  last  of  Its  data.  Thus,  a  close  request  means  *1  have  no  more  to  send* 

but  does  not  mean  *1  will  receive  no  more**  It  may  happen  (If  the 

upper  level  protocol  Is  not  well  thou^t  out)  that  the  cloelng  side  Is  unable 
to  get  rid  of  all  Its  data  before  timing  out.  In  this  event,  a  close  turns 
Into  abort  request,  and  the  cloelng  TCP  gives  up.  Because  cloelng  a  connection 
requires  communication  with  the  foreign  TCP,  connections  may  remain  In  the 
cloelng  state  for  a  short  time.  Attempts  to  reopen  the  connection  before 
the  TCP  replies  to  the  close  request  will  result  In  error  responses.  A 
close  service  request  also  Implies  the  push  function. 

9.2.14.2  PIN  exchange  examples.  The  PIN  control  flag  In  the  segment 
header  Is  exchanged  with  the  sane  synchronisation  mechanism,  the  three*-vay 
handshake,  used  for  connection  opening*  Prcm  the  TCP  entity  perspective, 
there  art  essentially  three  eases  for  PIN  exchange.  One,  the  local  ULP  in¬ 
itiates  connection  closing  vith  a  CLOSE  service  request*  Two,  the  remote 
TCP  entity  sends  a  PIN  segment  indicating  that  the  remote  UIP  has  issued  a 
close  request*  Three,  both  ULPs  simultaneously  issue  close  requests* 

9.2*14.2*1  Case  I:  local  ULP  initiates  connection  close*  In  this  case, 
a  PIN  segment  can  be  constructed  and  placed  on  the  outgoing  segment  queue* 

No  further  send  requests  from  the  ULP  will  be  accepted  by  the  TCP,  and  it 
enters  the  FINHTAIT-l  state.  All  segments  preceding  and  Including  FIN  will 
be  retransmitted  until  acknowledged*  When  the  other  TCP  has  both  acknowledged 
the  PIN  and  sent  a  FIN  of  its  own,  the  first  TCP  can  ACK  this  PIN.  Note  that 
a  TCP  receiving  a  FIN  will  ACK  but  not  send  Its  own  FIN  until  Its  ULP  has 
closed  the  connection  also. 


TCP  A 

TCP  B 

ESTABLISHED 

ESTABLISHED 

(Close) 

FIN-WAIT-I 

— > 

<SEQ- 1 OOXACKOOOXCTL-FX  N ,  ACK> 

— >  aOSE-«AlT 

nN-WAlT-2 

<— 

<S£Q*300><ACK«101  ><CTL-ACK> 

<—  close-wait 

TIHE-WAIT 

<— 

<S£q.300><ACK«I  01  XCTL-nu  .ACK> 

(Close) 

<—  UST-ACK 
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5.  TIME-WAIT  — >  <SEQ»101><ACK»301><CTL-^CK>  — >  aoSED 

6.  (2  MSL) 

CLOSED 


9 .2 .14 .2 .2  Csit  2t  TCP  receives  FIN  fro»  rtnote  TCP#  If  sn  unsolicittd 
FIN  arrives  from  the  netvork,  the  receiving  TCP  can  ACK  It  and  tell  the  ULP 
that  the  connection  Is  closing.  The  ULP  will  respond  with  a  close  request, 
upon  which  the  TCP  can  send  a  FIN  to  the  other  TCP  after  sending  any  remaining 
data.  The  TCP  then  waits  tntU  Its  own  FIN  Is  acknowledged  whereupon  It 
deletes  the  connection.  If  an  ACK  la  not  forthcoming,  after  the  ULP  timeout 
the  connection  Is  aborted  and  the  ULP  Is  Informed. 

9.2.14.2.3  Case  3;  ULPa  close  simultaneously.  Simultaneous  close  requests 
by  both  ULPa  at  aach  end  of  a  connection  cause  FIN  segments  to  be  exchanged. 
When  all  segments  preceding  the  FINs  have  been  processed  and  acknowledged, 
each  TCP  can  ACK  the  FIN  It  has  received.  Both  will,  upon  receiving  these 
ACKs,  delete  the  connection. 


TCP  A 


TCP  B 


1.  ESTABLISHED 


ESTABLISHED 


2.  (ULP  A  issues  CLOSE)  (ULP  B  Issues  aoSE) 

HN-WAIT-I  — >  <SEQ-l00><ACK-300><CTL-nN,ACK>  ...  FXN-WAIT-l 

<—  <SBQ«300><ACK-l00><CTL*riN,ACK>  <— 

...  <SEQ«lO0><ACK»3OO><CTL«nN,ACK>  — > 

3.  aOSINC  — >  <SEQ*l0lKACK-30lXCTLwACK>  ...  aOSINC 

<—  <SEQ«30l><ACK*l0l><CTL*ACK>  <— 

...  <SBQ-101XACK-301XCTL»ACK>  — > 


4.  TIME-WAIT 
(2  MSL) 
CLOSED 


TIME-WAIT 
(2  MSI) 
CLOSED 


9.2.14.3  Quiet  time  concept.  While  the  clock-based  ISK  generation  prevents 
overlap  of  sequence  number  use  under  normal  conditions,  special  measures  must 
be  taken  in  situations  where  s  host  ersshes  (or  rwstsrts),  resulting  in  a 
TCP's  loss  of  knowledge  concerning  the  sequence  numbers  in  use  on  active 
connections,  and  the  current  ISN  value.  After  crash  recovery,  a  TCP  may 
create  eegaents  containing  the  same  or  overlapping  sequence  numbers  ss 
those  in  precrssh  connection  Inca rnst Ions,  causing  confusion  am)  misdelivery 
at  the  receiver.  Even  hosts  managing  to  remember  the  time  of  day  used  as  a 
basis  for  l$N  selection  are  noc  immune  to  this  problem,  as  the  following 
example  illustrates r 


‘Suppose,  for  example,  that  a  connection  is  opened 
starting  with  sequanee  number  S.  Suppose  that  this 
connection  Is  not  heavily  used  and  that  eventually  the 
initial  sequence  number  fiWictioo  (ISN(t))  takes  on  a 
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value  equal  to  the  sequence  number,  say  SI,  of  the  last 
segment  sent  by  this  TCP  on  a  particular  connection.  Now 
suppose,  at  this  instant,  the  host  ersshes,  recovers,  and 
establishes  a  new  incarnation  of  the  connection.  The 
initial  sequence  number  diosen  is  SI  •  ISN(t)  last 
used  sequence  number  on  the  old  Incarnation  of  the  con¬ 
nection!  If  the  recover  occurs  quickly  enough,  any  old 
duplicates  in  the  network  bearing  sequence  numbers  in  the 
neighborhood  of  SI  may  arrive  and  be  accepted  ai  new  packets 
by  the  receiver  of  the  new  Incarnation  of  the  connection.” 

The  problem  is  that  the  recovering  host  may  not  know  for  how  long  it  crashed, 
nor  does  it  know  vihether  there  are  still  old  duplicates  In  the  system  from 
earlier  connection  incarnations. 

9.2.14.3.1  "Keep  quiet”  concept.  One  way  to  handle  these  situations  Is 
to  require  that  a  TCP  must  "keep  quiet”,  that  Is,  refrain  from  emitting 
segments,  for  s  maximum  segment  lifetime  (HSL)  before  assigning  any  sequence 
numbers.  This  quiet  time  restriction  allows  the  segments  from  earlier  con¬ 
nection  incarnations  to  drain  from  the  network. 

For  this  specification,  the  HSL  is  assumed  to  be  2  minutes.  This  Is  an 
engineering  choice,  and  may  be  dianged  as  experience  dictates.  TCP 
Implementors  violating  this  restriction  run  the  risk  of  causing  some  old 
data  to  be  accepted  as  new  or  new  data  rejected  as  old  duplicates.  Note 
that  if  s  TCP  is  reinitialised  yet  retains  Its  knowledge  of  sequence  numbers 
in  use*  the  quiet  time  restriction  does  not  apply;  however «  care  should  be 
taken  to  use  sequence  numbers  larger  than  those  recently  used. 

Kesets.  One  of  the  control  flags  of  the  TCP  header  Is  the  reset 
flag.  A  segment  carrying  a  reset  flag  set  true  Is  called  a  reset.  Kesets 
are  used  to  abruptly  close  established  connections,  refuse  connection  attempts, 
and  respond  to  segments  apparently  not  intended  for  the  current  incarnation 
of  a  connection.  The  following  paragraphs  define  the  rules  for  reset  genera¬ 
tion  and  for  reset  validation  and  processing. 

9.2.13.1  Keset  generation.  Each  paragraph  below  specifies  when  a  reset 
should  be  sent,  the  sequence  number  and,  when  needed,  the  acknowledgment 
number  necessary  to  make  the  reset  segment  acceptable  to  the  remote  TCP. 

When  either  ULP  of  the  communicating  ULP-palr  Issues  an  Abort  service 
request.  Its  local  TCP  Informs  the  remote  TCP  with  a  reset  segment  carrying 
a  sequence  number  field  equal  to  SENDJitXT.  As  a  general  rule,  reset  (KST) 
must  be  sent  whenever  a  segment  arrives  which  apparently  Is  not  Intended  for 
the  current  connection.  A  reset  must  not  be  sent  If  It  Is  not  clear  that 
this  Is  the  case.  Specific  examples  of  reset  generation  In  response  to 
misdirected  segments  ar^  presented  In  three  groups  of  states^ 

9.2.13.1.1  When  connection  does  not  exist.  When  the  connection  does  not 
exist  (l.e..  Its  state  Is  aoSEO)  then  a  reset  Is  sent  in  response  to  any 
Incoming  segment  except  another  reset.  In  particular,  SYNs  addressed  to 
nonexistent  connections  are  rejected  In  this  manner.  If  such  an  Incoming 
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•tg»nt  h*f  tn  ACK  field,  the  reset  segoent  takes  its  sequence  number  from 
the  ACK  field  of  the  Incomii^  segment;  otherwise,  the  reset  segment  takes  a 
sequence  number  value  of  tero  and  an  acknowledgment  number  equal  to  the  sum 
of  tYm  sequence  atmber  and  text  length  of  the  Incoming  segment*  The  con¬ 
nection  remalitt  In  the  CLOSED  state* 

9*2 .IS* 1*2  When  connection  Is  In  any  nonsynchronlsed  state.  When  the  con¬ 
nection  la  In  any  nonsynchronlsed  state  {LISTEN,  SYN-SENT,  SYN-RECEIVED) ,  a 
reset  Is  sent  In  the  following  cases:  The  Incoming  segment  acknowledges 
somethli«  not  yet  sent  (that  la,  the  segment  carries  an  unacceptable  ACK), 
or  an  Incoming  segment  carries  security  Information  which  does  not  exactly 
match  that  designated  for  the  connection*  Resets  generated  In  the  nonsynchro- 
nixed  states  are  made  acceptable  as  follows*  When  the  Incoming  segment  has 
an  ACK  field,  the  reset  segment  takes  Its  sequence  number  from  the  ACK  field 
of  the  incomiiv  segmint:  otherwise,  the  reset  segment  carries  a  sequence 
fwmber  equal  to  tero  and  acknowledgment  field  set  to  the  sum  of  the  sequence 
nuaber  ai^  text  lei^th  of  the  Incoming  segment*  The  connection  remains  In 
the  same  state* 


9.2*15, 1*3  When  connection  la  In  a  aynchronlted  state*  If  the  connection 
la  In  a  synchronlfed  state  (ESTA8LISK©,  FN-WAITI,  riN-WAlT2,  CLOSE-WAIT, 
aosiwc,  UST-ACK,  TIME-WAIT),  any  iiiacceptable  segment  (such  as  one  with 
an  out-of-wlnrfow  sequence  number  or  an  unacceptable  acknowledgment  number) 
must  elicit  only  an  mapty  acknowledgment  segment  containing  the  current  send 
sequence  number  (SEND  KEX7)  and  an  acknowledgment  indicating  the  next  sequence 
number  expected  to  be*’recelved  (RECVJIEXT)*  (Hote  that  If  the  unacceptable 
segaent  la  an  empty  ACK  segment,  replying  with  an  ACK  may  result  tn  a  cascade 
of  ACKa*  In  general,  do  not  ACK  an  unacceptable  empty  ACK  segment*)  The 
connection  rewilfm  In  the  same  state*  If  an  incoming  segment  hae  security 
Information  or  a  precedence  level  which  does  not  exactly  match  those  designated 
for  the  connection,  a  reset  is  sent;  ttie  connection  enters  the  CLOSED  state. 

The  reset  segment  takes  its  sequence  fumber  from  the  ACK  field  of  the  incoming 
segment* 


9.2.15.2  Reset  processing.  In  all  states  except  SYN-SEMT,  all  reset  (RST) 
segments  are  validated "by  checking  their  sequence  number  fields.  A  reset 
Is  valid  If  its  sequence  (umber  Is  In  the  connection’s  receive  window.  In 
the  SYN-SEMT  state  (a  RST  receive  In  response  to  an  Initial  SYN),  the  RST 
la  valid  If  the  ACK  field  acknowledges  the  SYM.  The  rscelver  of  a  RST  first 
validates  It,  then  changes  state.  If  the  receiver  was  in  the  LISTEN  state. 

It  Ignores  It.  If  the  receiver  was  In  SYN-RECRXVEO  state  and  had  previously 
been  In  the  LISTEN  state,  then  the  receiver  returna  to  the  LISTEN  state; 
otherwise,  the  receiver  aborts  the  connection  ami  goes  to  the  CLOSED  state. 

If  the  receiver  was  In  any  other  state.  It  aborts  the  connection  and  advises 
the  ULP  and  goes  to  the  CLOSED  state. 

9.3  TCr  header  format.  A  suMsry  of  the  concent#  of  a  TCR  header  follows: 
Mote  that  each  tick  mark  rtpresenta  one  bit  poeltlon.  Etch  field  description 
below  includes  its  name,  an  abbreviation,  and  the  field  ilit.  Where  applicable , 
the  unlti.  the  legal  range  of  valuet,  and  a  default  value  appears. 
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012  34SS7t9O12a48S7t»0l2 


8f  QUtNCI  NUMSEII 


ACKNOWLEOOMINT  NUM8IR 


WtNOOW 


CHECKSUM 


URGENT  ROWTER 


ORTlONt 


FIGURE  9.  TCF  hts4tr  lonMit. 


9,3. 1  Sourct  port. 


sbbrtv;  SRC  FORT 


Hold  sIsr:  )6  bits 


Tht  sourct  port  nuabtr. 


9.3.2  Dfstlnstlon  port* 


sbbrtv:  DEST  FORT 


fltld  sits:  lb  bits 


Tht  dtstinstlon  port  nuabsr. 


9.3.3  Stqutnct  nusbtr. 


sbbrtv:  SEQ 
units  :  oettts 


field  slst;  32  bits 
rsngt:  0  -  2**32-l 


Ususlly.  this  vslut  rtprtstnts  tht  stGutnet  isisbtr  of  tht  first  dsts  oetti 
of  s  stgatnt.  Howtvtr,  If  s  SYN  Is  prtstot,  tht  stqutnct  nisbtr  Is  tht 
Inltlsl  stqutnct  rttsbtr  (ISK)  covering  tht  SYN;  tht  first  dsts  octet  Is  then 
nuobtrtd 
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9,3,4  Acknowlsdwnt  puabtr* 


Abbrtv;  ACK 
units:  oetsts 


fitl4  sls«:  32  bits 
rAAgs:  0  -  2**32-l 


If  th*  ACK  control  Mt  to  oot.  tMo  ftoW  eonttlno  tho  »«lot  of  the  next 
•oquoneo  nuabor  that  tho  toodot  of  tho  tofoont  lo  oxpoetlng  to  rocolvo. 


9.3a5  Pats  Qgfstta 

•bbrtv:  noAs 
units:  32*bits 


fiAld  sist:  4  bits 
rsAit:  5  *  15 


dtfault:  5 


thto  ftold  indleotoo  tho  auAbor  of  32  hit  oordo  In  tho  ICP  hoodor.  fro* 
thto  »oXuo,  tho  boglimtm  of  tho  data  can  te  *"|;“**J*,.*^  ^r^^***" 
(avon  000  tneludini  optlooo)  la  an  Intogral  minbor  of  32  blta  long. 


9.3o6  lUstnftdo 

abbrsv:  aoat 


fitia  slst:  6  bits 


Rtsarvad  for  futurt  utt«  Ibist  bt  sot  to  toroo 
9a3,7  Control  Jlaii- 

abbrtv:  boXoif  fltl4  sUt:  4  bltsCfron  l#£t  to  right) 

UKCt  OrpAt  rolAttr  fitl4  tipifitoAt 

AOCt  AekA0iilt4cntAt  (i«14  •igAlflcoAt 

FSB:  Futh  Function 

UT:  tofft  tho  conntetlon 

$TB:  Synchroniso  stqooncs  nu^rs 

riN:  Bo  aort  4sti  froa  sondor 

Thtso  flogs  csrry  control  Inforaatlon  uft4  for  conntetlon  tstsbUthnsne, 
connoctlon  ttfalnstlon.  on4  connect  Ion  as inttnonco. 


9.3.8  Bin4ov. 


sbbroo:  VNDU 
units:  octets 


fitl4  sits:  2  octets 
ronp:  0  -  2**l6*l 


4ofoult:  none 


The  titabor  of  4ots  octets  beginning  with  the  one  tn4iesto4  In  the  •cknowl*' 
e4g«inc  flel4  uhidh  the  sender  of  this  segaint  Is  willing  to  eccoFt. 


9.3.9  Checksum. 

sbbrev;  none  flel4  site:  2  octets 

Tho  ehockav.  ftold  to  tho  U  Wt  «*o*.  tcpUoont  of  tho  ono'a  toylo»^ 
sua  of  oil  U  Wt  wor4s  it.  the  heeder  e«4  test.  The  ehecksua  sUo  • 

9b  Wt  pseudo  header  conceptual ly  preftsed  to  the  TCF  header.  This  pseu  o 
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hesdur  contains  tht  Sourca  Addrtss*  tht  Dastinatlon  Addrass,  tba  Frotoeol, 
and  TCP  aagaant  length.  Tha  chackaua  algorltha  la  defined  In  paragraph 
9.2  6. 


9.3.10  Uraant  pointer. 

abhravt  mtCFTIl  field  aitat  2  octets 

units:  octets  rangs:  0  •  2**16-i  default:  0 

This  field  Indicates  tha  current  value  of  tha  urgent  pointer  aa  a  positive 
offset  fron  tha  aequanct  mtnbar  In  this  aegaant.  The  urpnt  pointer  points 
to  tltt  aaquanea  nueher  of  tha  octet  follewlnc  tha  urgent  data.  This  field 
Is  only  to  ha  Interpreted  la  aegnants  vlth  the  UlC  control  hit  eat. 

9.3.11  Options. 

abhravx  OPT  field  else:  variable 

If  present t  options  occupy  apace  at  tha  tad  ^  the  TCP  header  and  ere  a 
•ultlpla  of  8  bits  la  lai^{th.  All  options  are  included  in  tha  chechaum.  An 
option  nay  beglo  on  any  octet  boundary.  There  are  M  cases  for  tha  foraat 
of  an  option: 


a.  A  ainglt  oaet  of  optlon-hlad. 

b.  An  octet  of  optioifiand,  an  octet  of  option>length»  and 
tht  actual  optloirdata  octets. 

Tha  opt Ion- length  counts  tha  too  octets  of  option-hind  and  option- length  as 
wall  as  tha  optioirdata  oaets.  Vote  that  tht  list  of  options  nay  be  shorter 
than  tha  data  offset  field  night  inply.  Tha  content  of  tha  header  beyond 
the  Cnd-of-Option  option  nust  be  header  padding  <i-e.,  aero). 

Currently  defined  options  include  (hind  indicated  in  octal): 


Kind 

Length 

Heaning 

0 

• 

End  of  option  list. 

1 

- 

g^peration. 

2 

4 

Maxinun  Segnent  Site. 

9.3.11.1  tnacific  option  definitions. 

9.3.11.1.1  End  of  oetion  list. 


ame  •  a 


PlCUhE  10.  End  of  option  list  code. 
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This  option  code  indicates  the  end  of  the  option  list.  This  might  not 
coincide  vith  the  end  of  the  TCP  header  according  to  the  Data  Offset  field. 
This  is  used  at  the  end  of  all  options,  not  the  end  of  each  option,  and 
need  only  be  used  if  the  end  of  the  options  would  not  otherwise  coincide 
with  the  end  of  the  TCP  header. 

9.3.11.1.2  No*operation. 


I  00000001 1 


KWO  -  1 

FIGURE  11.  No-operation  option  code. 

This  option  code  may  be  used  between  options,  for  example,  to  align  the 
beginning  of  a  subsequent  option  on  a  word  boundary.  There  is  no  guarantee 
that  senders  will  use  this  option,  so  receivers  must  be  prepared  to  process 
options  even  if  they  do  not  begin  on  a  word  boundary. 

9.3.11.1.3  Maximum  segment  else. 


00000010 


00000100  MAX  SCO  SIZE 


KINO  «  2  UNGTH  •  4 


FIGURE  12 .  Maxi  sum  segment  siae  option. 

If  this  option  is  present,  then  it  communicates  the  maximum  receive  segment 
size  at  the  TCP  which  sends  this  segment*  This  field  must  only  be  sent  in 
the  Initial  connection  request  (i.e. ,  in  segments  with  the  SYN  control  bit 
set).  If  this  option  is  not  used,  any  segment  size  is  allowed. 

9.3.12  Padding. 

abbrev:  none  field  size:  variable 

The  padding  is  used  to  ensure  that  the  TCP  header  ends  and  data  begins  on  a 
32  bit  boundary.  The  padding  is  composed  of  zeros. 

9.4  Extended  state  machine  specification  of  TCP  entity.  The  TCP  protocol 
entity  is  specified  with  an  extended  state  machine  made  up  of  a  set  of  states, 
a  set  of  transitions  between  states,  and  a  set  of  input  events  causing  the 
state  transitions,  the  following  specification  is  made  up  of  a  machine 
Instantiation  identifier,  a  state  diagram,  a  state  vector,  data  structures, 
an  event  list,  and  a  correspondence  between  events  and  actions.  In  addition, 
an  extended  state  machine  has  an  Initial  state  whose  value  is  assumed  at 
state  machine  Instantiation. 
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9.4.:,  instantiation  Identifier.  One  state  aechlne  Instance  exists 

for  ea« .  •  *incction.  A  connection,  and  hence  a  state  nachine*  is  uniquely 
named  by  i  oi  the  two  machine  instantiation  identifiers  that  exist:  the 

socket  pair  anc  uhr  local  connection  name. 

9*4. 1,1  Socket  pai.r  iueniifigr.  TCP  segments  delivered  by  the  network 
and  cmnection  establishment  sf  rvice  requests  (Active  Open,  Active  Open  with 
Data,  Full  Passive  Open,  ana  Unspecified  Passive  Open)  carry  and  thus  are 
bound  to  8  connection  with  the  following  values: 

a*  source  address 

b.  source  port 

c.  destination  address 

d.  destination  port 

9.4.1.:  Local  connection  name.  A  TCP  entity  assigns  an  identifier,  a 
local  coruiectlon  name,  that  appears  in  all  service  responses  and  all  service 
requests  except  for  active  and  passive  open  requests. 

9.4.2  Stale  diagram.  The  following  diagram  summarizes  the  state  machine 
for  the  TCP  entity. 

Please  note  the  diagram  Is  Intended  only  as  a  summary  and  does  not  supersede 
the  formal  definition  that  follows. 

9.4.3  State  vector.  The  elements  comprising  the  state  vector  of  a  TCP 
entity  appear  below.  Each  element  name  Is  followed  by  the  name  of  the 
corresponding  record  element  in  the  state  vector  structure  "sv**  declared  In 
Section  6,3,4. 1. 

a.  state  name  (sv, state):  the  current  state  ot  the  entity  state 

machine  from  the  following  list:  CLOSED,  LISTEN,  SYN  RECVD, 
SYN_SENT,  ESTAB,  HN  WAIT!,  FINJtfAITl,  aOSE  WAIT,  CLOSING, 
UST^ACK,  TIMEJ^AIT.'*  " 

b.  source  address  (sv.source^addr):  the  Internet  address  naming 
the  location  of  the  local  ULP. 

c.  source  port  (sv.source^ort):  the  identifier  of  the  local  ULP. 

d.  destination  address  (sv.destination_addr}:  the  internet  address 
of  the  location  of  the  the  ULP  at  the  other  end  of  the  connection. 

e.  destination  port  (sv.destlnatlon__port ):  the  identifier  of  the 
ULP  at  the  other  end  of  the  connection. 

f.  Ico  (sv.lcn):  local  connection  name,  the  laentlfler  associated 
with  this  end  of  the  connection. 

g.  open  mode  (sv.open  mede):  the  type  of  opin  request  issued  by 
the  local  ULP,  either  ACTIVE  or  PASSIVE. 
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h*  original  precedence  (sv.orlgl^nal^rec):  one  of  eight  levels  of 
special  handling  requested  by  the  local  ULP  in  the  open  request* 

1*  actual  precedence  (sv.actual^rec):  one  of  eight  levels  of 
special  handling  negotiated  during  connection  establlshaent 
and  verified  throughout  connection  lifetime* 

J.  security  (sv.sec):  Information  (including  security  level,  cob- 
partment,  handling  restrictions,  and  transmission  control  code) 
defined  by  the  local  ULP* 

k.  sec  raises:  security  structure  mhich  specifies  the  alloved 
ranjes  in  coaparteent,  handling  restrictions,  transaission 
control  codes  and  security  levels* 

1*  ulp  tlaeout  (sv*ulp_tlasout):  the  aaxlaua  delay  alloved  for 
data  transmitted  on'^the  connection* 

a*  ULP  tiwout  action:  In  the  event  of  a  ULP  tlaeout,  determines 
if  the  connection  is  terminated  or  an  error  is  reported  to  the 
ULP* 

n*  send  unacknowledfsd  sequence  taiaber  (sv*seod  una):  oldest 
unacknowledged  send  sequence  lumber  (l*e*  left  edge  of  send 
vindov)* 

o*  send  next  sequence  nihber  (sv*sendjiext):  sequence  number  of 
the  next  data  octet  to  be  sent* 

p.  send  free  sequence  nuhber  (sv*sendjfree):  sequence  tuaber  of 
the  first  free  octet  in  the  send  queue  (l*e*  the  next  octet  to 
be  received  froa  the  local  ULP}* 

q*  send  %nndov  (sv.sendjvndv);  alloved  lumber  of  octets  that  may 
be  sent  to  the  r«ote  TCP  relative  to  the  send  unacknovledged 
sequence  number* 

r*  send  urgent  sequence  luaber  (sv.send  urg):  sequence  tuaber  of 
the  last  octet  of  urgent  data  in  sen?  stress* 

s«  seirf  push  sequence  nuhber  (sv*sendj)ush):  sequence  luaber  of 
the  last  octet  of  pushed  data  in  the  send  s trees. 

t*  send  last  vindov  update  1  (sv*send_lastupl );  sequence  lusber 
of  the  incoming  segsent  used  for  last  vindov  update. 

u.  send  last  vindov  update  2  (sv.send_^lastup2 ):  acknovledgaent 
fusber  of  the  incoming  segsent  use?  for  Ust  vindov  update. 

V*  sewl  initial  sequence  tuaber  (sv*send_lsn):  sequence  nusber  of 
the  original  SYN  sent. 
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V.  tend  fin  flag  (av.aand^flnflag):  Indlcataa  that  the  local  ULP 
haa  iaauad  a  Cloaa  raquaat. 

X.  tend  Baxlaum  aegoent  aize  (av.aandjuxjieg):  aaxlaua  a  Iced 
aegaent  to  be  aant  to  the  reaote  TCP  on  thla  connection. 

y.  aenl  queue  (av.aendjqtieue):  location  of  data  received  froa  the 
local  ULP  and  elthe?  awaiting  acknovledgaent,  or  awaiting  trana- 
aiaaion.  Thia  area  ia  aeceaaed  only  by  the  data  aanageaent 
routinee. 

x.  receive  next  aequence  niaber  (av.recvjnaxt):  acqucnce  ci«aber  of 
next  data  octet  expected  to  be  received. 

aa.  receive  aave  aequence  niaber  (av.recv_jiaxt):  aequence  niaber 
of  next  data  octet  to  be  delivered  to*the  local  ULF. 

bb.  receive  window  (av. recv_wndw):  allowed  niaber  of  data  octeta 
to  be  received  froa  the*reaote  TCP  atarting  with  the  receive 
next  aequence  ais^r. 

cc.  receive  alloc  (av.recv  alloc):  the  niaber  of  data  octeta  that 
will  be  accepted  by  the  local  ULP. 

dd.  receive  urgent  aequence  niaber  (av.recvjirg):  aequence  niaber 
of  the  laat  octet  of  urgint  data  in  receive  atraaa. 

ee.  receive  puah  aequence  niaber  (av.recv  puah):  aequence  niaber  of 
the  laat  octet  of  puahad  data  in  receTva  atraaa. 

ff.  receive  Initial  aequence  niaber  (av.recv^ian):  aequence 
niaber  of  the  SYN  received  froa  reaote  T&. 

gg.  receive  fin  flag  (av.recv^finf lag):  indlcataa  that  fin  haa 
been  received  froa  the  reMte  TCP. 

hh.  receive  queue  (av.recvjqueue):  location  of  data  accepted  froa 
reaote  TCP  before  dell'^ry  to  local  ULP.  Thia  area  ia  aeceaaed 
only  by  the  data  aanageaent  routinaa. 

9.4.4  Data  atructurea.  The  TCP  entity  atate  aachine  referencea  certain 
data  areaa  corraaponding  to  the  atate  vector,  the  aervice  requeata  and 
reaponaes  on  the  upper  interface,  and  the  aervice  requeata  and  reaponaca  on 
the  lower  interface.  For  clarity  in  the  eventa  and  actiona  aection,  theae 
data  atructurea  are  declared  in  ADA.  However,  a  data  atructure  eay  be  pat- 
tially  typed  or  untyped  where  apeelfic  foreata  or  data  typea  are  iapleaentar 
tion  dependent. 

9.4.4.1  State  vector.  The  TCP  entity  atate  vector  ia  defined  in  paragraph 
9.4.1  above.  The  correaponding  atructure  ia  declared  aa: 
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iv:  ststt^vtctorjtype; 

typt  ststt^ytetor^typs 
rseord  ”  " 

Stitt:  (aOSKD,  LISTEN,  8YN  RECVD,  SIN  SENT 
ESTAB,  HN  WAITl,  HN  WAIT2, 
aOSEJWAITTCLOSIHC,  LAST_ACK,  TIHEJfAIT); 
souret^sddr:  Iddrtss^typt;  “  "" 

sour  ct^oTt :  TWOJDCTETS ; 
dost  lust  lon_addr:^  tddrtss  typt; 
dtstiostion^ort:  TVOJDCTTtS; 

Icn:  iottfsr; 

optnjndt:  (ACTIVE,  PASSIVE),* 
orlfntl^prte:  prscsdsnes^typt; 
setusl^rte:  prtetdsDctjtypt; 
ste:  sseurlty_typt;  "" 
sse_rsn|t8:  slcurlty^stnict; 

ULP3iMOut:  InttprT 

CLP*'tlMoutjictloa:  lotsgsr; 

St i2[_uns !  Itq usnet^nu^r^typt ; 
so  ad3ksxt  I  stq  usnMjDuibtrjty  pt ; 
sood^ftstt  ssqutnet^mabst^typs; 

St  nd^vodv:  Int  tgt  r;* 

stikQiU*  stqutnet_cfei^r_typt: 
ttiid3ush:  stqutnet_Buabtr  typt; 
stbd^Ustupl:  stqusIet_au«Etr_typt; 
stndTlsstuplt  stqusnetjMabtrjtypt; 
stod^tn:  stqutnet^m&r^typt; 
stod^ltfltf*  booHsn;  ** 
stiid38aL.stf:  Inttpr; 
stnd^uButt  tlatdjtutut  typt; 
rt  cv3txt  t  s  tq  usnet^fst&r^typt ; 
rt  cv^svt :  stq  ut  net jMibt  » 

rtev^ndv:  Inttpr;**  " 
rtev3lloci  int  tgt  r; 
rtcv^rg:  stqutnet^mtbt  retype; 
rtcv^ush:  stqusnM^auiibtTjtyp; 
rtev^lsn:  stqutnetJnt^r^yHi 
rtev^lnflsg:  beoUsn; 
rtcv^utut:  qutut^typt; 
tod  rtcord;  "" 

9.d.4,2  Frot  ULP>  Tbt  frotJILP  structurt  bolds  tbs  strviet  rtqutst 
prswttrs  sod  dots  sssodlsttd**vitb  cht  strviet  rtqutst  prltltlvts  ts 
spelfltd  in  psrsgrtpb  8«3«  Tbs  frotJULF  strueturt  is  dtclsrtd  ts: 

typt  frotJJLF_typ  l£ 
rteord  " 

rtqutstjosM:  (Uospcif itd_FtstivtJ>pn,  Full  Pssslvt^Opn, 

AetlvtJDpnT  Activt3>P*®J^t*L?*^** 

Stod,  Allocstt,  Clott,  Abort,  Status); 


98 


1-258 


MILITARY  STANDARDS:  TCP 


MIL-STD  1778 


MIL-STD-1778 
12  August  1983 


•ourct__sddr 

•ourcsjport 

dts t Inst loa^sddr 

dsstinstlon^ort 

len 

ULP^tlMout 
ULF^^t  las  ou  t^s  ct  ion 
prsctdtnes 
sscurlty 

sscjrsogts 

dst7 

dsts^Isngth 
pusb^flag 
urgt'ntjflsg 
snd  rscoTd; 

9.A.4.3  To  PLP.  THt  toJJlP  structurt  holds  ssrvict  rtsponst  psrsasttrs 
snd  dsts  ss  spsclflsd  in  psrsgrsph  6*A*  Although  ths  structuts  is  coapossd 
of  ths  psrsBstsrt  froa  sll  ths  ssrviet  rsqutsts,  s  psrticulsr  ssrvict 
rtsponst  will  ust  only  thost  structurt  tltatnts  corrtspondlng  to  its  sptclfitd 
psrsatttrt*  Tbt  to  Ulf  structurt  is  dtclsrtd  ss: 


typt  toJJiF_^typt  is 
rtcor? 

stzvict  rtsponst  :  (OFEN  ID»  OFEN  FAZLt  0FEN^SUC®8S, 

DELX^E.  aOSiNG.  TERMINATE,  ERIOR); 

sourct^sddr 

touret^ovt 

dtstinstioD^addr 

dost  ins  tionjport 

len 

dsts 

dsts^ltngth 

urtt7t_flsg 

trrorjissc 

sts^Jl‘^bloek:  ststus^block__typt; 
tnd  rtcoTd; 

typt  ststus  blodc  typt  is 
£tcord 

conntction__ststt 
stndjuindow 
rtctTvt^indow 
saount Jof^unscktd^dst  s 

saount^o^ ®  • 

urtsnt^stTtt 
prtctdTnct 
stcurity 
stc  rsngts 

ULF^iwout 
Ul?”t  iatout jict  ion 
tnd  rtcord; 
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9*4 *4 *4  To  NET*  The  to_NET  structure  holds  the  service  request  persaeten 
end  date  sssoclsted  with  the  NET_SEND  service  request  specified  in  psrsgrsph 
8.2,  This  structure  directly  coTresponds  to  the  toJfET  structure  dscUred 
in  psrsgrsph  8.3*2  of  the  lover  layer  service  requiTeaents  section.  The 
toJTET  structure  is  declared  as: 

type  to  hTT^type  jU 
recor?  * 
sourcejiddr 
des t i nat ion^edd r 
protocol  " 
type^ofjiervice  is 
reTor? 

precedence 

reliability 

deUy 

throughput 

reserved 

end  record; 
tiiM^to^live 
dont^fragesnt 
length 

sag:  segesnt^type; 

options 
end  record; 

JLESSJSI*  froe^KET  structure  Holds  the  service  response 
parssaters  and  data  associated  vith  the  NET^DELIVER  service  response i  as 
specified  in  psrsgrsph  8.2.2*  This  structuTe  directly  corresponds  to  the 
froa^NET  structure  declared  in  paragraph  8.3.3  of  the  lover  layer  service 
requireaents  section.  The  froaJTET  structure  is  declared  as: 

type  froaJIET^type  ^ 
record  ~  ” 

sourcejiddr 
des t i n7t  ion^add r 
protocol  "" 
type^of  service  is 
re7or7 

precedence 

reUsbiUty 

daisy 

throughput 

reserved 

end  record; 
length 

sag:  segaent_type: 
options 
error 
end  record; 


MILITARY  STANDARDS:  TCP 


MIL-STD  1778 


MIL-STD-1778 
12  August  1983 


Stg— nt  typt«  A  ••gatat^^typt  structura  holds  s  TCP  ssgntnt  asds 
up  of  s  hssdtr  portion  snd  s  dsts  portion  ss  specif iod  in  Section  9«3.  A 
segnent^type  structure  is  declared  ss: 

type  stgaent^typt  is 
record  ~ 

source^ort  :  IWOjDCTETS; 
destinstioQjport  :  TWOJ)CrETS; 
se^Qua  :  FOUR  OCTETS; 

sek  iBiB  :  POUbToCTETS; 

dsts  offset  :  B/U>  OCTET; 
reserved  :  SIX  EI«THS  OCTET; 
urgjlsg  :  ONE“bIT; 
sck^flsg  :  ONE^BIT; 
push  flsg  :  ONE  BIT; 
xst  flsg  :  0NB“bIT; 
syo"’flsg  :  0NE"bIT; 
fin*“flsg  :  0NE"“bIT; 
wndw  :  TWOJXrTETS; 
checksua  i  TU03>CrETS; 
urgptr  :  W03)CTETS; 
options  :  is  7rrsy  of  OCTET; 
padding  :  is  array  of  OCTET; 
data  :  is  array  of  OCTET; 
end  record; 

9. 4. 4,7  Suppleaental  type  declarations* 

type  address^type  is  FOUBjOCTETS;  _ 

type  sequenc^isiabe retype** is  FOUBjOCTETS; 
type  precede OMjcype'^is  INTEGER  range  0,.7; 
type  security_t7pt  is 
record 

security^ltvel  :  HALF^  OCTET; 
coapsrtatnt  :  TWO  'OCTETS; 
hai^Ung  :  TWOj)CTETS; 

transjcontrol^code  :"THREEjOCrETS; 
end  recoTd;  ” 

subtype  OCTET  is  INTEGER  rai^e  0..233; 
subtype  HALF  OCTET  is  INTEGER  range  0..15: 
subtype  FIVEHcIGHTHS  OCTET  is  INTEGER  range  0..31; 
subtype  7V0  OCTETS  il  INTEGER  range  0..2**16-1; 
subtype  THR?E  OCTETS  is  INTEGER  rar^e  0.  .2**24-!; 
subtype  FOUR  OCTETS  is  INTEGER  range  0.. 2**32-!; 

NULL  RESERVE?  :  cow  tent  FIVE  EIGHTHS  OCTET  :•  0; 

OPTIONLESS  HEADER  :  cowtant  INTEISER  S? 

NORMAL  *  :  constant  INTEGER  :•  0; 

NULL  :  constant  INTEGER  :•  0; 

— NULL  assuatd  to  be  outside  the  sequence  waber  space. 
DEFAULT  PRECEDENCE  :  cowtant  INTEGER  :•  0; 
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DEFAULT  PRECEDENCE 

default" timeout 
default"timeout  action 
default" sec  list 

ONE  M1NUTE_TTL 
THIS  ADDRESS 
TCP  Id 


cons  tint  INTEGER  0; 
coMtsnt  INTEGER  :•  01111000(8); 
cons tint  INTEGER  :■  1; 
security  list; 

comtent"lNTEGER  00111100(8); 
coMtsnt  INTEGER;  — Upl.  dependent 

com  tent  INTEGER;  —reference  [3] 


9.4.5  Event  list.  The  events  for  the  TCP  entity  stete  eechine  ere  drewn 
from  the  service  request  primitives  defined  in  the  eervlci  definition  of 
Section  6.2.  Optionel  service  request  peremeters  ere  shoiin  in  breclcets. 

The  cepitelixed  list  of  peresetecs  represent  the  ectuel  vslues  of  the 
paraatters  pessed  by  the  service  prieltive.  The  event  list! 


Unspecified  Psssive  Open  (S0UR(2_P0RT , 

TIMEOUT)  {.TIMEOUT  ACTION) 
(.PRECEDENCE)  ( .SEC  RANGES )) ; 


b. 


Full  Psssive  Open  (SOURCE_PORT. 

DEST1N4TION  PORT,  DESTINATION  ADDRESS, 
{ .TIJCCUT)  T.TIJSOUT  ACTION) 
{.PRECTDENCE)  (.SEC  IjUiGES)); 


c. 


Active  Open  (SOURCE  PORT, 

OESnNATlON  PORT,  DESHNATIONJIDDRESS 
(,T1«0UT)  T.TI«0UT  ACTION)  " 
l.PRECTOENCE)  (.SECURITY)); 


d.  Active  Open  w/dsts  (SOURCE  PORT, 

DESTINATION  PORT,  DESTINATION  ADDRESS 
(,TI«OUT)  T.TIICOUT  ACnON)  I.PRECEDENa) 
(.SECURITY)  );  DATA,"DATA_LENCTH.  PUSH_ 

FLAG,  URCENT^FLAC); 

Send  (LCK,  DATA,  DATA^LENGTH ,  PUSH^FUG,  URCENT^PUC  (.TIMEOUT)); 
f.  Allocste  (LCN,  OATA^UNCTH) 


f.  Close  (LCN) 
h.  Abort  (LCN) 


1.  Ststus  (LCN) 

i.  N-ET  DELIVER  (SOURCT  ADDRESS,  DESTINATION  ADDRESS.  PROTOCOL. 

TOS I  precedence,  rellsbllliy,  delay,  throughput  1, 
OPTlONSitecurltyl ,  LENGTH,  DATA) 

k.  Ketrsnsmifsion  Timeout 

l.  ULP  Timeout 

m.  Time  W*ii  Tla^out 
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9.A.6  Evsnti  snd  actions*  This  ssction  Is  orgsnlstd  io  thrtt  psrts. 

Tht  first  psrt  contains  s  decision  table  representation  of  state  sachine 
events  snd  sciicns.  The  decision  tables  are  organised  bgr  state;  each  table 
corresponds  to  one  event.  The  eecend  part  specifies  the  decision  functions 
appesring  at  the  top  of  eseh  eoluvi  of  a  decision  table.  These  functions 
exanine  attributes  of  the  event  and  the  state  vector  to  return  a  set  of 
decision  results.  The  results  becoee  the  eleaents  of  osch  coluvi.  The 
third  part  specifies  action  procedures  appearing  at  the  right  of  every 
row.  Each  row  of  the  decision  table  coabines  the  decision  results  to 
detemine  appropriate  event  processing.  These  procedures  specify  event 
processing  algorithas  in  detail. 

9.4 .6.1  Decision  tables.  The  Status  event  can  occur  in  any  state  except 
closed:  TCP's  action  is  to  return  the  current  state^vector  inforaation  as 
specified  in  the  STATUS  RESPONSE  service  response.  If  the  priaary  state 
vector  eleasnt  is  not  dUnged  in  the  decision  table  row  corresponding  to  an 
event,  the  "priaary*  state  reaaitvi  unchanged.  The  chcchsua  is  assuaed  to  be 
coaputed  for  all  incoaing  segasnts*  When  the  coaputed  checksua  does  not 
aatch  the  segaent's  header  checksua  field,  the  segaent  is  discarded  without 
being  scknowledged. 

9.4.6. 1.1  State  •  closed. 


legend 

d  ^  ^don't  csre"  condition 

Eviut:  Active  Open  (LOCAi  PORT,  REHOTE  PORT,  RCHOTE  ADDRESS 

ITIHESjTI  iTIMtOOT'ACriOH)  iMiaUKCEl  ISECUHinl) 

TABU  1.  Active  open  event  in  a  closed  state. 


Actions: 


MSOUSCIS 

SIC 

suf’ic 

MIC 

OSIN* 

SLlOWfO 

WO 

4 

issoe  c  iasufiiCiiNT  sisouecfs  “> 

VIS 

NO 

ISSOS  !*  SfCUSlTV/MISCfOfNCf  NOT  AUOWlO  1 

VIS 

VIS 

OSIN.  CIN.SVN  lAlONIi.  SV  STATS  •  SVN.SINT 

Event:  Active  Open  with  Dsta  (LOCAL  PORT,  REMOTE  PORT,  REMOTE  ADDRESS. 

ITIJCOUTI  (TIMEOUT’" aaiON)  IPRECEOCSCE) 
(SECURITY}  DATA.  bJfTA  UKCTH,  PUSH  fUC. 
URGENT  rUC) 
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TABLE  II,  Active  open  vlth  data  cvtnt  In  •  closed  sttf. 

Actions: 


SEtOUnCEl 

SEC 

turfic 

SSEC 

OSEN? 

ALLOWED 

NO 

4 

Essos  riNSurrictENT  nttouncES 

YES 

NO 

Esnon  r  sEcuniTY/sfiECEDENCE  not  allowed 

YES 

YES 

OVEN.  QEN.SYN  IWITH.DATAI;  tV.  STATE  •  SYN.SENT 

Event:  Full  Pessive  Open  (LOCAL  PORT,  REMOTE  PORT,  REMOTE  ADDRESS, 

(TIMEOUT)  (TIMEOUTjCaiON)  (PRECIdCNCE)  (SECJtANCES) ) 

TABLE  III,  Full  pessive  open  event  in  e  closed  stett. 


Actions: 


SESOUSCtt 

SEC 

turric 

SAIC 

orEN» 

ALLOWED 

NO 

4 

Essos  t 'iNturrtciENT  nESOunctt  ’) 

YES 

NO 

inson  < 'SECUSJTY/SfllCtDENCt  NOT  ALLOWED  '1 

YES 

YES 

OHN  SV  STATE  •  LtSTEN 

Event:  Unspeclfl«!  Passive  Open  (LOCAL  PORT,  (TIHEOUT)  (TIMEOUT  ACTION] 

tPREcTDCNCEl  (SECJIANGESI  ) 

TABLE  IV,  Unspecified  passive  open  event  in  a  closed  state. 

Actions: 


SISOUSCIS 

SIC 

SUM  1C 

MIfC 

0«N» 

allowed 

NO 

4 

ISSOS  t -mSMMlCIfNT  SfSOunCES  “1 

Yis 

NO 

lesos  8  siCLMHTY»esiciDlNCt  not  allowed  'i 

VIS 

YES 

OetN  SV  STAIt  •  LISTEN 

Event:  Send  () 

or  Close  ( ) 
or  Abort  () 
or  Allocate  () 

Actions:  error  ("Connection  docs  not  ealst.*) 
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Evtnt:  NETJ>ELIVER  (SOURCE^ADDRESS.  DBSTlNAT10Nja)DR£SS,  PROTOCOL, 

~  T0S(pr7ctdtnct,  rtlisbllltjT  8tUy,  throughput), 

OPTIONS{ttcurltyl.  UNGTH,  DATA) 

TABLE  V.  Wtt  dtlivtr  tvtnt  Ip  •  clotod  itttt* 


Actions: 


0«A.6.1.2  Ststt  •  Xlsttn# 

Evtnt:  dost  (LCN) 

or  Abort  (LCK) 

Aetiont:  rtsct  stll(UC);  tVtSUtt^CLOSED 


Evtnt:  AXIocttt  (LCM,  DATAJLENOTE) 
Act loot t  ntv  tlloestion 


Evtnt:  Stnd  () 

Actions:  trror  (”lIltgsX  rt^uttt.*) 


Evtnt:  Activt  Opto  () 

or  Activt  Optn  vith  dtts  () 
or  PuXX  ftssivt  Optn  () 
or  Unsptcifitd  ftssivt  Optn  () 


Actions:  trror  (‘Coontction  tXrtsdy  tsistt**) 

Evtnt:  NET^DCLXVER  ($OURCZja>DRES$,  DESTimTXONJU>DRESS,  PROTOCOL, 
TOSlprtctdtnct,  rtXisbiXityT  8tXty,  throughput), 
OPTXONSUtcurity),  LEHCTM,  DATA) 


•  V  V 

N  V  * 
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TABLE  VI.  Ntt  dtllvtr  tvtnt  in  •  litf  n  ttatt. 


Acciona: 


avN  uc 

ON  MATCH 
?  ? 


av  aaic 
vt 

no  awe 

.-NO  ACTION 


wan  laiQ) 


OWATta  WCOaO.aVN:  OIN.aVN  (WfTH.J^i; 
oa  IQUAL  av.  aTATI  •  aVN.WCVD 


uaa  wcoao.avN:  tukmjmc:  oiN.avN  iwirH^ACio: 
av.  aTATI  •  avN.aicvo 
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Event:  Retrinemisson  Timeout 
Actions:  retransmit 


Event:  ULP  Timeout 

Actions:  if  (ULP^tlmeou traction  ■  1) 

then  open_fsll;**sv.8tate  <■  CLOSED; 
else  report^tlmeout; 


Event:  NET^DELIVER  ( SOURCE JU)ORESS,  D£STINATIOHJU)DRESS,  PROTOCOL, 

""  T0S( precedence,  reliability,  delay,  throughput], 

OPTIONS (security],  LENGTH,  DATA) 


TABLE  VIII .  Net  deliver  event  In  a  SYN  SENT  state. 

Actions: 


ACK 

STATUS 
TIST  1 

AST 

ON 

» 

SEC 

MATCH 

? 

SV  AAEC 

VS 

SEQ  AAEC 

SYN 

ON 

? 

FIN 

ON 

? 

MONK 

NO 

NO 

d 

d 

d 

ASSET  (SEQ) 

lirw 

NO 

YES 

d 

NO 

d 

>  >  NO  ACTION 

Nomi 

NO 

YES 

QAEATEA 

OA  EQUAL 

YES 

NO 

ASCOAD^SYN:  SSND.ACX  (SV.  AECV.ISN  4.  1);  SV.  STATE  - 
SYN^AECVO 

MONI 

NO 

YES 

QAEATEA 

OA  EQUAL 

YES 

YES 

AECOAD.SYN:  SENO^ACK  (SV.  AECV.ISN  i.  1);  SAVE.FIN: 

SV.  STATE  •  SYN^AECVO 

NON! 

NO 

YES 

LESS 

YES 

NO 

AECOAO^SYN.  AAISE.AAEC;  SEND^ACK  (SV.  ASCV^ISN  1); 

SV  STATE  •  SYN.AECVD 

NONE 

NO 

YES 

LESS 

YIS 

YES 

AfCOAD^SYN:  F,A!SE_FAIC;  8ENO_ACX  (SV.  A|CV„ISN  •  1): 
SAVE.FIN:  SV.  STATE  •  SYN.AECVO 

msm 

VIS 

d 

d 

d 

d 

- NO  ACTION 

mVAL 

NO 

d 

d 

d 

d 

ASSET  (SEQ) 

mvAi. 

YIS 

d 

d 

d 

d 

>  NO  ACTION 

VALID 

NO 

NO 

d 

d 

d 

ASSET (SEQ) 

VALID 

NO 

YES 

QAEATEA 

mm 

d 

ASSET (SEQ) 

VALID 

NO 

YES 

LESS 

OA  equal 

IQIIII 

B 

>  NO  ACTION 

VALID 

NO 

YES 

LESS 

OA  EQUAL 

YES 

NO 

AAISE^AAEC;  CONN.OAEN:  SV.  STATS  •  ESTAS 

VALID 

NO 

YES 

LESS 

OA  EQUAL 

YES 

YES 

AAiSE.AAEC;  CONN.OACN:  SH^FIN;  SV.  STATE  •  CLOSE. 

VALID 

YES 

d 

a. 

d 

d 

OAENrAIL:  SV  STATE  .  CLOSED 
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State  ■  SYK  RECVD. 

Event:  Clot.  (LCN) 

Actions:  sendJ'.  ;  ‘‘v.state-FIN  WAITl 


Event;  Abort  (LCN) 

Actions;  reset  (CURRENT);  reoet  8elf(UA);  sv.state^LOSED 


Event;  Send  (LCN,  DATA,  DATA  LENGTH.  PUSH  FLAG,  URGENT  FLAG  iTIMEOUT] 
lTIMEOUT_ACriON]“  *“ 

TABLE  IX.  Send  event  In  a  SYN  RECVD  state. 

Act  Ions: 


RESOURCES 

SUFFIC 

SEND? 

NC 

ERROR  ('‘INSUFFICIENT  RESOURCES  ") 

YES 

SAVE^SENO^OATA 

Event:  Allocate  (LCN,  DATAJLENGTH) 
Actions:  new  allocation 


Event:  Active  Open  () 

or  Active  Open  with  data  () 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  ("Connection  already  exists.") 


Event:  Retransalislon  Tiwyut 


Actions:  retramalc 


Event:  ULP  Tiaeout 

Alt  Ions:  If  (ULP^tiaeou  traction  •  1) 

then  reaet  (CUR^NT);  opcnfail;  sv.state^CLOSED 
else  report  tiaeout; 
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Event:  NETJDELIVER  ( SOURCE JU)DRES S ,  DESTINATION^ADDRESS,  PROTOCOL, 

TOS I precedence,  reliability,  delay,  throughput), 
OPTIONS [security),  LENGTH.  DATA) 

TABLE  X,  Net  deliver  event  In  a  SYN  RECVD  state. 


Actions: 


SEQ# 

STATUS 

RST 

ON? 

SEC 

PREC 

MATCH? 

OPEN 

MODE? 

SYN 

IN 

WNOOW 

ACK 
STATUS 
TEST  1 

ZERO 

RECV 

WNOOW 

PIN 

SEEN? 

tNVAL 

NO 

d 

d 

d 

d 

d 

d 

SENO^ACK  ISV  RECV.  NEXT) 

IfiVAL 

YES 

d 

d 

d 

d 

d 

d 

-  >  NO  ACTION 

VALID 

NO 

NO 

PASS 

d 

d 

d 

d 

RESET  (SEG)  PART_RESET.  SV,  STATE  ■  LISTEN 

VALID 

NO 

NO 

ACT 

d 

d 

d 

d 

RESET  ISEGI;  OPENPAIL:  SV.  STATE  •  CLf'  ‘*0 

VALID 

NO 

YES 

d 

NO 

NONE 

d 

d 

-  -  NO  ACTION 

VALID 

NO 

YES 

d 

NO 

INVAL 

d 

d 

RESET ISEG) 

VALID 

NO 

YES 

d 

NO 

VALID 

NO 

NO 

CONN_OPEN:  SV.  STATE  -  ESTAB 

VALID 

NO 

YES 

a 

NO 

VALID 

NO 

YES 

CONN_OPEN:  SET_FIN;  SV.  STATE  ■ 
CLOSE_WAIT 

VALID 

NO 

YES 

d 

NO 

VALID 

YES 

d 

UPDATE:  CHECK.URC.  SV.  STATE  •  ESTAB 

VALID 

NO 

YES 

d 

YES 

d 

d 

d 

RESET  (SEG);  OPENPAIL:  SV.  STATE  -  CLOSED 

VALID 

ves 

d 

PASS 

d 

d 

d 

d 

PART.  RESET:  SV.  STATE  •  LISTEN 

1  VALID 

YES 

d 

ACT 

d 

d 

d 

d  i 

OPENPAIL.  SV.  STATE  •  CLOSED 

State  ■  ESTAB. 

Event:  Close  (LCN) 

Actions:  send^fin;  sv.state-FINJWAIT? 

Event:  Abort  (LCN) 

Actions:  reset (CURRENT) ;  reset  self(UA);  sv.state*CLOS£D 
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Event:  Send  (LCN,  DATA,  DATA  LENGTH,  PUSH_FLAG,  URGENT^FLAG  [TlrtEOUTl 
(TIMEOUT  ACTION r 


1985 


TABLE  XI*  Send  event  In  an  estab  state* 


Actions: 


RESOURCES 

SUFFIC 

SEND? 


NO  ERROR  ( -INSUFFICIENT  RESOURCES  ”) 

YES  DISPATCH 


Event:  Allocate  (LCN,  DATA_LENGTH) 
Actions:  new  allocation 


Event:  Active  Open  () 

or  Active  Open  with  data  () 
or  Full  Passive  Open  (} 
or  Unspecified  Passive  Open  () 

Actions:  error  (Xonnectlon  already  exists*"} 


Event:  RetransolSBlon  Tlaeout 


Actions:  retransmit 


Event:  ULP  Timeout 

Actions:  if  (ULP  timeout  action  •  1) 

then  r«et  (CURRENT);  reset^self (UT);  sv*state»CLOSED 
else  reporter Imeout 

Event:  NET^DELIVER  (SOURCEja>DRESS,  DESTltUTION_ADDRESS,  PROTOCOL, 
^  TOS( precedence,  reliability,  delay,  throughput] 

OPTIONS (security],  LENGTH,  DATA) 


no 
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TABLE  XII.  Not  deliver  event  In  sn  estab  state. 


SEC  SYN  ACK 
PREC  IN  STATUS 
MATCH?  WNOOW  TEST  2? 


SEND.  ACK  ISV.  RECV.NEXTI 


-  -  NO  ACTION 


RESET  iCSGi;  RESET  .SELF  ISP);  8V.  STATE  -  CLOSED 


-  -  NO  ACTION 


INVAL  I  SEND.ACK  ISV.  RECV_NEXT1 


;  RESET _ 


RESET.SELF  (RA):  SV  STATE  -  CLOSED 


9.4,6, 1.6  State  »  aOSE  WAIT. 

Event:  Send  (LCN,  DATA,  DATA  UNCTH,  PUSH  PUG,  URGENT  FUG  {TIHEOUTj 
(TIMEOUT  ACTION r 


TABLE  XIII.  Send  event  In  a  CLOSE  UAIT  state. 


Actions: 


•yyy 

V*  j 

VvS 

m 


RESOURCES 

SUFFIC 

StND> 

NO  ERROR  r  INSUFFICIENT  RESDURCES  "I 
Yf  S  I  DISPATCH 
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Event:  Active  Open  () 

or  Active  Open  with  date  () 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  ("Connection  already  exists.") 

Event:  Close  (LCN) 

Actions:  send_fin;  sv.state-lAST_ACK 

Event:  Abort  (LCN) 

Actions:  re8et(CURRi;NT) ;  resetjself (UA) ;  sv.state^CLOSED 


Event:  Retransmission  Timeout 
Actions:  retransmit 

Event:  ULP  Timeout 

Actions:  if  (ULP^timeou traction  ■  1) 

then  reTet (CURRENT);  reset_self (UT);  sv.state-CLOSED 
else  reporter  imc out 

Event:  NET_DELIVER  (SOURCEJIDDRESS,  DESTINAT10Nja)DRESS,  PROTOCOL* 
TOS [ precedence ,  reUabiUtyT  delay,  throughput), 
OPTlONSisecurity],  LENGTH,  DATA) 


TABLE  XIV,  Net  deliver  event  in  a  CLOSE  WAIT  state. 

Actions: 


8EQ» 

STATJS 

AST 

OM 

SEC 

MIC 

MATCH> 

svw 

IW 

WWDOW 

ACK 
STATUS 
TEST  2' 

ZEAO 

SECV 

WNDOW 

PIW 

SEEW 

> 

tNVAl 

WO 

a 

a 

d 

d 

d 

SEWD^ACK  iSV  eiCV^WKT! 

INVAL 

VIS 

a 

d 

d 

d 

d 

.  NO  ACTION 

VALID 

wo 

wo 

d 

d 

d 

d 

ecsn  tsECi  seset.sclf  isai.  sv  state  •  closed 

VALID 

wo 

VES 

wo 

wowc 

d 

d 

..  NO  ACTION 

valid 

wn 

VIS 

wo 

IWVAl 

d 

d 

SEND.  ACK  tsv  AECV.WEXT 

VALID 

wo  * 

VES 

wo 

valid 

WO 

wo 

UADATE  ACCEAT 

valid 

1 

1  VES 

wo 

valid 

WC 

VES 

UAOATE  ACCEAT  SET _ FIN  SV  STATE  •  CLOSE. WAIT 

valid  ] 

WO 

i 

wo 

VALID 

VIS 

d 

UADATI  CHICK. UAG 

valid  i 

WO 

L 

VES 

e 

d 

d 

AfSET  !SEG:  SESET.SELF  iSFl  $V  STATE  .  CLOSED 

VALID 

1  Hi 

i  1 

d 

d 

d 

d 

AESET.SIlc  ISA  S\  STATE  .  CLOSED 
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9,4,6.1.7  State  »  closing. 

Event:  Allocate  (LCN|  DATA^LENGTH) 
Actions:  nev  allocation 


Event:  Send  () 

or  Close  () 

Actioi«:  error  ("Connection  closing*") 


Event:  Active  Open  () 

or  Active  Open  with  data  () 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  (Connection  already  exists*  ) 


Event:  Abort  (LCN) 

ActioiM:  reset  (CURRENT) j  resetjiel£(UA);  sv,statt»CLOSED; 

Event:  Retransaiesion  Tiasout 
Actions:  retransait 


Event:  ULP  Tiasout 


Act  ions: 


1£  (ULP  tl«*out-«ctlon  •  1) 

r<Mt  (7UIUIBNI)!  t«Mt_MU(UT);  iv.^tatt-CLOSED 
•iM  riport_tl*«ou«  ” 


Event: 


HET  1*LIVER(S0U*CE  AOBEWS,  DESnittIIOH_ABI*ESS,  PROTOCOL, 

TOSlprletdtne#.  r«U«blUty,  a«l»y.  throaihputl. 
options  I  Mcurltyl,  UHCTH,  DATA) 
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TABLE  XV .  Net  deliver  event  in  a  closing  sf  tc» 


Actions: 


SiQf 

STATUS 

» 

AST 

ON 

> 

SEC 

PAEC 

MATCH’ 

SYN 

IN 

WNOOW 

ACK 
STATUS 
TEST  2’ 

FIN 

ACK'D 

? 

INVAL 

NO 

d 

d 

d 

d 

SEND.ACK  (SV.  RECV.NEXT) 

mvAi 

VIS 

d 

d 

d 

d 

-  -  NO  ACTION 

VALID 

NO 

NO 

d 

d 

d 

VALID 

NO 

VIS 

NO 

NONE 

d 

-  -  NO  ACTION 

VALID 

NO 

YES 

NO 

INVAL 

d 

SEND.ACK  ISV  AECV.NEXri 

VALID 

NO 

YES 

NO 

VALID 

NO 

USOATE 

VALID 

NO 

YES 

NO 

VALID 

YES 

STAAT.TIME.WAIT:  SV  STATE*  TIME  .WAIT 

VALID 

NO 

YES 

YES 

d 

d 

ntsr  ISSO);  aiSr.SELF  ISFI;  SV.  STATE  -  CLOSED 

VALID 

YES 

d 

d 

d 

d 

SESET^SELF  mA)  SV  STATE  •  CLOSED 

9.4.8. 1,8  State  «  FIN  WAITl. 

Event!  Allocate(  LCN,  DATA^LEHGTH  ) 
Actions:  nav^al location 

Event:  SendO 

or  CloaeC) 

Actioiii:  errorCConnection  closing.”) 


Event:  Active  OptnO 

or  Active  Open  vith  dataf) 
or  Full  Fasiive  OpaaO 
or  Unspecified  Fassive  OpenO 

Actions:  error(”Conneetlon  already  exists.*) 
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Ewnt:  Abort  (  LQl  ) 

Actions:  rsst t (CURRENT) ;  rtsstjislf (UA) ;  sv.stst CLOSED 

Event:  Retrsnsalssloo  Tlasout 
Actions:  rstrsnsnlt 


Event:  ULP  Tlneout 

Actions:  if  (ULP^tinsout  set  ion  •  1) 

then  rt7st(CURRrNT);  rsset^sslf (UT);  sv.ststs*CLO$ED 
slss  r^ort  tlJMout 


Event:  NET_DCLlVER(SOURCEja)ORESS,  OESTINATIOITADORESS,  PROTOCOL, 
TOS [ pr7esdsncs »  relisbilityT  throughput )i 

OPTIONS (security],  LENGTH,  DATA) 

TABLE  XVI.  NET  deliver  event  in  s  PIN  WAITI  etste. 

Act  ions : 


BIOS 

STATUS 

f 

SST 

ON 

> 

tic 

H*.SC 

MATCH* 

IVN 

•N 

WNOOW 

ACK 
ITATyS 
TIST  2’ 

2ISO 

RiCV 

WNOOW 

SIN 

ACK'O 

I 

SIN 

ON 

» 

MVAl 

NO 

4 

4 

4 

4 

4 

4 

IINO.ACK  IIV  eiCV«N|XT! 

MVAC 

vtt 

4 

4 

4 

4 

4 

4 

.  -  NO  ACTION 

VALiO 

NO 

NO 

4 

4 

4 

4 

4 

RllfT.  eillT.IILS  (SPi.  SV  STATC  .  CIOSID 

VAIO 

NO 

Vfl 

NO 

NONI 

4 

4 

4 

-  -  NO  ACTION 

VALID 

NO 

Vft 

NO 

INVAL 

4 

4 

4 

IINO.ACK  ISV  RICV.NIXT) 

VALID 

NO 

vit 

NO 

VALID 

NO 

NO 

NO 

USOATI.  ACCIST 

valid 

NO 

Vlt 

NO 

VALID 

NO 

NO 

VII 

USOATI.  ACCIST.  IIT.SIN.  SV  STATI  •  CLOSING 

VALID 

NO 

VII 

NO 

valid 

NO 

VII 

NO 

USOATI.  ACCIST.  SV  |TAT|  •  SlN.WAlT  2 

VALID 

NO 

vif 

NO 

valid 

NO 

! 

VII 

VII 

USOATI.  ACCIST.  IIT.SIN:  START. TlMI.IMAiT 

IV  IT  ATI  •  TMI.WIAIT 

valid 

NO 

VII 

NO 

VALID 

^  ■■  ; 

1  ••o 

4 

USOATI 

valid 

NO 

Vlt 

NO 

VALID 

■■  *^1 

IvW 

4 

USOATI.  tV  ITATI  •  SIN.INAIT  2 

VALID 

NO 

VII 

1 

VII 

■1 

■1 

■i 

B 

RIICT  iSIGl.  RIBIT.BILS  (|S|. 

IV  ITATI  •  CLOUD 

VALID  1 

VIS 

4  1 

4 

4 

4 

4 

._1J 

RfllT.llLS  'RAi  tV  STATC  •  CLOSiO 

.V  V 
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9.4.6. 1.9  Ststt  ■  FIM  WAIT2. 

Evint:  Abort (  LGN  ) 

Actions:  rtstt (CURRENT);  rsstt_tolf (UA);  •v.ttats^LOSBD 

Evtnt:  Allocstt(  LCN,  DATAJ2NGTH  ) 

Actions:  nsv^sl Iocs t Ion 

Evtnt:  StndO 

or  ClostO 

Actions:  trrorCCcnnsction  closii^.*') 

Evtnt:  Actlvt  OptnO 

or  Activt  Opsn  with  dstsO 
or  Full  Psssivt  OpsnO 
or  Untptcifisd  Psssivt  OptnO 

Actions:  trrorC ‘Conns ct ion  tlrttdy  sxlsts.‘) 

Evtnt:  Rttrsnssission  Tistout 

Actions:  rstrsnssit 


Evtnt:  ULP  Tlstout 

Actions:  if  (ULP^tistout  action  •  1) 

thtn  rsTtt(CURRFNT);  rtstt^stlf (UT);  sv.ststt<LOSED 
tlst  rsport  tlMout 


Evtnt:  N£T_DELZVER(SOURaja)ORESS,  DCSTINATION^ADORESS.  PROTOCOL, 
TOSiprtctdtnct.  rtlitbilitv7  dtltv,  throughput), 
OPTXONSistcurityl,  UHCTH.'OATA)  ’ 
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TABLE  XVII,  Net  deliver  event  In  e  FIN  WAIT2  state. 


Actions: 


tlQ# 

SYATUS 

? 

nsT 

ON 

? 

SEC 

SREC 

MA7CH> 

SYN 

IN 

WNDOW 

ACK 
STATUS 
TEST  2> 

ZERO 

RECV 

WNDOW 

SIN 

ON 

? 

‘ 

mVAL 

NO 

d 

d 

d 

d 

d 

SEND.  ACK  ($V  RECV.  NEXT) 

INVAL 

YES 

d 

d 

d 

d 

d 

-  >  NO  ACTION 

VALID 

NO 

NO 

d 

d 

d 

d 

RESET  (SEO):  RESET.SELF  ISR):  SV.  STATE  •  CLOSED 

VALID 

NO 

YES 

NO 

NONE 

d 

■■ 

*  -  NO  ACTION 

VALID 

NO 

YES 

NO 

mVAL 

d 

d 

SEND.  ACK  ISV.  RECV.  NEXT) 

VALID 

NO 

YES 

NO 

VALID 

NO 

NO 

UROATE:  ACCERT 

VALID 

NO 

YES 

m 

VALID 

NO 

YES 

UROATE:  ACCERT;  SH.RlN  START_TIME_WAIT. 
tv.  STATE  •  TIME.WAIT 

VALID 

NO 

YES 

NO 

VALID 

YES 

d 

UROATE 

VALID 

NO 

YES 

YES 

d 

d 

■i 

RESIT  (SEO).  RESIT.SELF  (BF);  SV  STATE  •  CLOSED 

d 

d 

d 

- 

RESET. SELF  iRA):  SV  STATE  -  CLOSED 

9,4,6.1.10  Stste  *  last  ACX, 

Event:  Abort (  Ld  ) 

Actions:  reset  self(UA):  sv.stste-CLOSCD 


SB 


;V . ' 


,  **. 

*.*A*-*-* 
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Event:  RetreniBltilon  TlMOut 
Act Iona:  retranaalt 

Event:  ULP  Tlatout 

Act  lorn:  if  (UUP^tiBeout  ection  •  1) 

then  reMt(CURR£NT);  reietjielf  (UT);  iVtCtate^CLOSED 
else  report^tlMout 


Event:  NETJDELIVER(SOURCEja)ORESS,  DESTINATXON_ADDItESS.  PROTOCOL. 

T0S( precedence  I  reliebilitpT  deity,  throughput] 
OPTIONS (tecurlcy I .  LENGTH.  DATA) 

TABLE  XVIII.  Net  deliver  event  in  t  LAST  AQC  tttte. 


Actione: 


iiQ# 

STtTUI 

I 


ACK  INK 
STATUS  ACK‘0 


MATCH*  WHDOW  TIST  2? 


lEOi^rali 

MO  1 

1  4  1 

vAim 

MO 

VIS 

■9 

VAIIO 

MO 

VIS 

NO 

VAIIO 

MO 

VIS 

m 

VAiiO 

MO 

VIS 

NO 

VAUO 

TfS 

vfs 

VIS 

VAIIO 

TfS 

4 

4 

StNO.ACXlSV  RCCV^HIXT} 


--  HO  ACTtOH 


tUr  (StOl:  IIISIY..SILI  ISH;  SV  STATt  •  CiOtCD 


..  IfOACTIOli 


tisfT.siti  luci  sv  sTATf  •  ctosin 


SUIT  tUO):  tlSr.Sfir  ISXI:  SV.  STATf  «  CiO^IO 


etSfT^SIVl  <tAl  sv  STATf  •  ClOSfO 
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Evsnt:  StndO 

or  CXoitO 
or  AlXoeatoO 

Actions:  orrorCConotctlon  closing*") 


Evsnt:  Actlvi  Opsn() 

or  Active  O^n  with  dstsO 
or  Full  Psssivs  OpsnO 

or  Unspsclfisd  Psssivs  OpsnO 

Actions:  srror( "Connect ion  slrssdy  exists*") 

Event:  Tine  Wait  Tlweout 

Actions:  reset^self (UC);  sv*stsCe<»CL08ED 

Legend 

d  •  "don't  cere"  condition 

Event:  NET^OELlVEKSOUECEjUDOItESS.  (E$TXNAnOIIJ0DIUiS$,  PIOTOOOL, 
T0S( precede nee*  reli shill tyT  delay,  throughput). 
OPTXONSlsecurity],  UNGTH.  DATA) 

TABLE  XIX*  Wet  deliver  event  in  a  TIME  WAIT  state* 

Actions: 


SfOV 

•tATUS 

f 

MT 

ow 

f 

SIC 

MIC 

MATCH* 

IVN 

m 

wttoowr 

ACK 

iTATUi 

TfiT  V 

m 

ON 

I 

StVAl 

NO 

4 

4 

4 

4 

ilNO.ACKliV  mCV^NCXT) 

SIVAI 

Vf$ 

4 

4 

4 

m 

-  -  NO  ACTION 

VAMO 

NO 

NO 

4 

4 

B 

■filT  1110).  'HilT^mi  tiSi:  sv  iTATf  •  ClOifO 

VAtlO 

NO 

VII 

NO 

Nom 

4 

-  -  NO  ACTION 

VAUO 

NO 

Vfi 

NO 

SIVAI 

4 

HNO^ACKliV  eCCV.NCXTl 

VAl« 

NO 

Vii 

HO 

VAUO 

NO 

--  NO  ACTION 

VAUO 

NO 

vu 

NO 

VAUO 

Vfi 

ilNO^ACX  tiv  aCCV^NCXTt:  llfiTAAT.TlMC..WAlT 

VAUO 

NO 

Vfi 

Vfi 

4 

4 

milT  lilOK  MilT^ilLl  iv  iTATf  «  CiOitO 

VALiO 

Vfl 

4 

4 

4 

4 

eCilT.ifU  tSAi.  iV  STATI  •  CiOifO 
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9, A, 5, 2  ^clslon  functions.  The  following  functions  exsalne  inforaetlon 
contained  In  interface  parasMters*  interface  data,  and  the  state  vector  to 
SMke  decision.  These  decisions  can  be  tliought  of  as  further  refina^nts 
of  the  event  and/or  state*  The  return  values  of  the  functions  represent 
decisions  made. 

9. 4.6. 2.1  ACK  on?  The  ACK_on  friction  dsteiminas  whether  the  acknowUdg- 
■cnt  field  of  the  incoming  segment  is  In  use.  The  data  effects  of  this 
function  arc: 

a.  Data  examined  only:  from^NET.seg.ack^flag 

b.  Return  values: 

NO  —  indicates  the  ACK  flag  is  false  and  the  ACK  nu^er 
should  not  be  examined 

TES  —  it^lcates  that  the  ACK  flag  is  true  and  the  ACK  Qui6er 
is  in  use 

if  (fromJIRT.seg.ackjflag  •  TRUE) 
then  return  (TES) 
else  return  (NO); 

9.4.6. 2. 2  ACK  status  testlT  The  ACK^status^testJ  function  compares  the 
ACK  number  of  the  incoming  segment  witbTthe  current  send  variables  to  deter¬ 
mine  whether  the  ACK  is  valid.  This  function  is  intended  for  use  during 
connection  establishwnt  when  "old  duplicate**  ACKs  cannot  occur.  The  data 
effects  of  this  function  are: 

a.  Data  examined  only: 

fromJiET.aeg.ack^mm  sv.sendjsext 

froaTNET.seg.ack^flag  av.send^una 

b.  Return  values: 

NONE  **  no  ACK  appears  in  the  incoming  segment 
INVALID  —  the  Incoming  segment  carries  an  ACK  which  is 
outside  the  send  window 

VALID  —  the  Incoming  segment  carries  an  ACK  inside  the  aand 
wlisiow  uhleh  should  be  used  for  update 

—During  connection  establishment,  an  ACK  is  valid  If 

—it  imllM  iemidt  send  window  because  old  ACKa  do  not 

— cidst  for  this  connection  Incarnation. 

—Check  for  presence  of  ack  flag. 

If  (fromJIET.seg.ack^flag  •  FALSE  ) 
then  retlTrn  (NONE) 

elae  —Validate  ACK  againsf.  current  aend  window 

If  (from_HET.sef.ack_mm  -<  sv.send^una) 
or  (f7ao  NET.seg.ack  num  >  sv.iend^next) 
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then  return  (INVALID  )  —present  but  unscceptable 

else  return  (VALID);  —present  end  Inside  send  window 

9,4. 6. 2. 3  ACK  status  test2?  The  ACK_atatus_test2  function  exanlnes  the 
ACK  nu^er  of  the  lncomii«  segment  agalTit  the^current  send  variables  to 
determine  whether  the  ACK  Is  valid*  Thia  function  Is  Intended  for  use  after 
connection  establishment  when  old  duplicate  ACXs  can  legally  occur.  The 
data  effects  of  this  function  are: 

a*  Data  cxaiRlnad  only: 

froaJIET.seg.ack^flag  sv.send^next 

f  r  omJJET  •  s  eg*  ack*mm 

b*  Return  values: 

NONE  —  no  ACK  appears  In  the  Incoming  segment 
INVALID  —  the  Incoming  segment  carries  an  ACK  for 
something  which  has  not  yet  been  sent* 

VALID  —  the  Incoming  segment  carries  an  ACK  which  either 

falls  In  the  window  (and  should  be  used  for  update) 
or  duplicates  a  previous  ACK* 

-Hlfter  a  connection  Is  established,  an  ACK  Is  valid  If 
—It  ACKs  something  sent  on  this  connection  Incarnation* 

— <heck  for  presence  of  ack  flag* 

II  (fromJ«ET,seg*ack_llaf  •  FALSE) 

then  return  (NONE) 

else  —Validate  ACK  against  current  send  window 

If  (from^NET.seg.ack^num  >  sv.send^next) 

then  return  (INVALID)  —present  but  unacceptable 

else  return  (VALID);  —present  and  okay 

9*4, 6*2*4  Checksum  check?  The  checksua_check  function  computes  the  check¬ 
sum  of  an  Incoming  segment  ai^  compares  lt~aplnst  the  checksum  field  in  the 
header  of  the  Incoming  segment*  The  data  effects  of  this  function  are: 

a*  Data  examined  only: 

all  fields  of  fromJfET.seg  fromJJET* protocol 

from_MET*sourct_addr  fromJIET.  length 

fromYfET* destination  addr 
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b.  Return  values: 

NO  — ‘  indies Les  that  the  cooputed  checksum  does  not  natch 
the  value  in  fron^KET.s eg. checksum 

YES  indicates  that  the  coaputed  checksun  matches  the 
value  in  from^NET.s eg. checksum 

’--‘The  checksun  algorithm  is  the  16  bit  one's  complement  of  the 
—one's  complenent  sun  of  all  16  bit  words  in  the  segment 
—header  and  segment  text.  If  a  segment  contains  an  odd  number 
—of  octets,  the  last  octet  is  padded  on  the  right  with  seros 
—to  form  a  16-bit  word  for  checksum  purposes. 

—While  computing  the  checksum,  the  checksum  field  itself  is  replaced 
— vith  seros. 

—The  checksum  Includes  a  96-bit  pseudo  header  prefixed  to  the 
—actual  TCP  header.  The  pseudo  header  contains  the 
—source  address,  the  destination  address,  the  protocol  identifier 
—and  the  length  of  the  TCP  segment  (not  counting  the  pseudo  header) 
—as  passed  by  the  NET^DELIVER  service  primitive. 


souacE  aODSESi 


OESTINATtON  ADDSEtt 


ZESO 


SaOTOCOL 


SEGMENT  LENGTH 


FIGURE  14.  Checksum  check  function. 


—The  actual  computation  is  implensntation  dependent. 

9.4 ,6.2.5  FIN  ACK'd?  The  FINJLCK'd  function  examines  the  acknowledgment 
field  of  the  incoming  segment  to^determine  whether  this  segment  ACKa  a  pre¬ 
viously  sent  FIN.  The  data  effects  of  this  function  are; 


a.  Data  examined  only; 

f  r  om_NET. seg . ack^f lag  s v . se  nd^f 1 nf lag 

fromJlET.seg.ack^nua  sv.send^next 

b.  Return  values: 

NO  —  the  Incoming  segment  does  not  ACK  the  FIN 

YES  —  the  incoming  segment  does  carry  an  ACK  of  the  previously 
sent  FIN 


—The  sv.send^f  inf  lag  indicates  that  the  ULP  has 

—Issued  a  CLOSE,  The  FIN's  sequence  number  is  one  less  than 

— sv.send^next. 

if  (sv.send^f inf  lag  •  TRUE) 
then 
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if  ((froiiJIET,seg.ick_£lsg  -  TRUE)  and 

(fras^NET.seg.ackjQua  ■  tv.send^next) ) 
then  retara  (YES) 
else  return  (NO) 

9.4.6.2.6  FIN  on?  The  PIN^^on  function  determines  whether  the  incoming  seg¬ 
ment  carries  a  FIN  indicating"" the  remote  side  has  no  more  data  to  sendi  The 
data  effects  of  this  function  are: 

a.  Data  examined  only:  from_NET.seg.ifin_flag 

b.  Return  values: 

NO  —  the  segment  does  not  contain  a  FIN 

YES  —  the  segment  does  carry  a  FIN 

—The  segment  header  field  seg.fin_flag  indicates  the 
—presence  or  absence  of  a  FIN. 

if  (fromJIET.seg.flnjeiag  -  FALSE) 
then  return  (NO) 
else  return  (YES); 

9.4.6.2.7  PIN  seen?  The  PIN^seen  function  examines  both  the  Incoming  seg¬ 
ment  and  the  sv.recv  variables  for  the  previous  or  current  presence  of  a  FIN 

from  the  remote  TCP.  This  fvnction  is  used  in  the  established  state  because 

a  FIN  may  have  been  recorded  during  connection  opening.  The  data  effects  of 
this  function  are: 

a.  Data  examined  only: 

f romJIET.seg.f Injflag  sv. recv^f inf lag 

b.  Return  values: 

NO  —  No  FIN  has  been  received  from  the  remote  TCP  in  this 
or  previA4S  segments. 

YES  —  A  FIN  has  been  received,  either  In  the  incoming  seg¬ 
ment  or  a  previous  segment. 

-Hi  PIN  received  during  connection  opening  is  saved  in 
— sv.recv_^finflag.  A  FIN  is  present  in  an 
— Incomlif  segment  if  from^NET.seg.fin^f lag  is  set  true. 

if  ((  sv. recv^finflag  ■  TRUE  )  or 

(from  NET.seg.f in_f lag  •  TRUE  )) 
then  return  TyES) 
else  return  (NO); 
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9. 4, 6. 2. 8  Open  «odc?  The  openjK>de  function  deteralnes  whet  kind  of  open 
service  request  the  local  ULP  Issued,  The  data  effects  of  this  function 
are: 


a.  Data  examined  only:  sv.openjude 

b.  Return  values: 

ACTIVE  —  the  ULP  requested  an  Active  Open  with  or 
irithout  data  for  this  connection. 

PASSIVE  —  the  ULP  request  a  Full  Passive  Open  or  an 

Unspecified  Passive  Open  for  this  connection. 

—The  type  of  open  request  is  recorded  in  sv.open^mode. 

if  (sv.open_^node  ■  PASSIVE) 
then  return  (PASSIVE) 
else  return  (ACTIVE); 

9. 4. 6. 2. 9  Sv  prec  vs  seq  prec?  The  sv^rec^vsjieg  prec  function  compares 
the  precedence  recorded  in  the  state  vector  a^Tlrmt  the  precedence  level  of 
the  incoming  segment.  The  data  effects  of  this  function  are: 

a.  Data  examined  only: 

s  V .  origl  nal  j>r  ec  f  r  om  JIET.  type  jof^se  rvice .  precede  nee 

b.  Return  values: 

LESS  -  precedence  in  sv  <  segment  precedence 
EQUAL  -  precedence  in  sv  «  segment  precedence 
GREATER  -  precedence  in  sv  >  segment  precedence 

if  (sv.ori^nal^prec  <  from^NET. precedence  ) 
then  return  (LESS) 

else  if  (sv.orlginal^prec  •  froa^NET. precede nee  ) 
then  return  (EQUAL) 
else  return  (GREATER); 

9.4.6.2.10  Resources  suffic  open?  The  resources^suff ic^open  function 
examines  the  internal  resources  available  in  this  TCP  entity  to  deteimine 
whether  another  connection  can  be  supported.  The  data  effects  of  this 
function  are: 

a.  Data  examined  only:  —implementation  dependent 

b.  Return  values: 

NO  —  ii^icates  that  another  connection  cannot  be  supported 
at  this  time. 

YES  —  iirficstes  that  Internal  resources  are  sufficient  to 
support  another  connection 
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—This  function  is  hssad  on  the  sssuaption  thst  e  TCP  entity 
— hss  finite  resources  nsde  up  of  table  space,  storage  capacity, 
—and  other  iapleasncation  dependent  areas.  Although  the  aaount 
—of  these  resources  aay  either  be  fixed  at  systen  configuration 
—or  vary  dynaslcally  according  to  systea  usage,  aore  connections 
— «ay  be  requested  than  can  be  supported  by  the  entity. 

if  (enough  resources  are  available  for  another  connection) 
then  return  (TES) 
else  return  (NO); 

9.4.8.2.11  Resources  suffic  send?  The  resources_suffic_send  function 
exaaines  the  resources  of  this  TCP  connection  to  deteralne  if  aore  data  can 
be  accepted  froa  the  UIP  for  transfer.  The  data  effects  of  this  function 

are: 


a.  Data  ezaained  only:  — lapleaentation  dependent 

b.  Return  values:  w 

NO  —  lirflcates  that  data  cannot  be  accepted  froa  the  ULP 

at  this  tiae. 

TES  —  ii^icates  that  internal  resources  are  sufficient  to 
accept  and  transfer  aore  ULP  data 

—This  fimction  is  based  on  the  sssuaption  that  a  TCP 
—connection  has  finite  resources.  Although  the  aaount  of 
—these  resources  aay  be  fixed  at  connection  establlihasnt, 
—or  vary  over  connection  lifetiae,  at  soae  point  a  sending 
— UIP  aight  exceed  the  TCP  entity's  capacity. 

if  (  enough  resources  are  available  to  handle  this  SEND  ) 
then  return  (YES) 
else  return  (NO); 

9.4.6.2.12  RST  on?  The  RST  on  function  exaaines  the  reset  flag  of  the 
incoaing  segMOt's  Iteader  to  fiteraine  the  presence  of  a  RSTr  The  data 
effects  of  this  faction  are: 

a.  Data  aiaalned  only:  froaJIET.seg.rst^flag 

b.  Return  values: 

NO  —  the  incoait^  segasnt  does  not  contain  a  RESET 
TES  —  the  incoaing  segasnt  does  carry  a  RESET 

if  (froaJIET.seg.rst^flag  •  FALSE) 
then  ret^n  (NO) 
sloe  return  (TES); 

9.4.6.2.13  Sec  astch?  The  secjMtch  faction  coapares  the  security  pera- 
asters  (including  security  level, “coape rtasnt,  transaisslon  control  code. 
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•ni  har^Ur^  rMtrictiont)  dtfinad  in  the  state  vector  against  those  accoB** 
panying  Incoaing  segaent.  The  data  effects  of  this  function  are: 

Data  exaained  only: 

!ic9jiET«optionsIsecurity]  ev.sec 

b*  Return  values: 

NO  —  The  values  ^.n  the  state  vector  do  not  natch  those  of 
the  incoming  segnent* 

YES  —  The  security  infoimation  exactly  Batches  that  in  the 
state  vector. 

—The  security  infonatlon  is  not  carried  in  the  segnent  header 

—but  is  passed  by  the  netuoik  protocol  entity  in  the 

— NETJUSl  IVER  option  parsBeter* 

if  ( f ronJ^ET. opt ions t security)  ■  sv.sec) 
then  return  (YES) 
else  return  (NO); 

9.4,^- 2, U  Sec  prec  allyedt  The  sec^recjil lowed  fimction  enaaines  the 
security  and  precetence  information  requested  by  a  UIP  in  a  connection  open 
request  aid  based  on  the  InpleBentation  enviroinent  (l*e.,  secure  host, 
imclessified  systen,  etc.)  detemines  whether  this  TCP  entity  can  support 
then.  The  data  effects  of  this  fmetion  are: 

a.  Data  enaained  only: 

fronJOLP .precedence  fronJUlP. security 

b.  Return  values: 

NO  —  This  TCP  entity  cannot  support  the  requested  security 
and  precedence. 

YES  —  The  security  and  precedence  requested  can  be  supports 

—This  decision  is  iapleaentation  dependent. 

9.4.6.2,15  Sec  range  Batch?  The  sec^rangejMteh  function  diecks  if  the 
security  paraaeters  (including  security^levelT  coapartBsnt,  transaission 
control  code,  and  handling  res trict ions )  in  the  incoaing  segaent  fit  within 
the  security  ranges  specified  in  the  security  list. 

The  data  effects  of  this  function  are: 

—  Data  exaained  only: 

froB  nct.options  (security)  sv.secjLsnges 
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—  Ksturn  vslust 

MO  —  Ths  vAitttt  In  tht  ioconiof  tsfssnt  «r«  not  V7lthln 
tbt  rnngts  spoelfiod  In  tht  ststt  vtcotr. 

TES  Tht  vtiutt  In  tht  Incoaing  stgntnt  trt  vlthn  tht 
rtngtt  tptcifltd  in  tht  ststt  vtetor* 

9.4.6.2.16  Stc  nrtc  attch?  Tht  ttcjrtc  nttch  function  conptrts  tht  prtct- 
dtnet  Itvtl  tnd  stcurltj  info notion  (including  stcurity  Itvtl,  conptrtntnt, 
(f4Q§Blitlon  control  codt«  tnd  htndllng  rtstrlctiont)  dtfintd  in  tht  stttt 
victor  igsiost  thost  of  tht  inconing  stgnsnt*  Tht  dttt  offsets  of  this 
fwiction  trsx 

t«  Dttt  cctnintd  only: 

froi  MET. typo  of  ttrvict.prtctdtnct  sv.ste 
fronJ«7.  opt  ionsTitcuri  tyl  tv.  tctua_^rtc 

b.  Etturn  vtluts: 

MO  —  Tht  Mcurity  tnd  prtetdtnet  of  tht  ttgntnt  do  not 
mtdk  thott  of  tht  stttt  vtctor. 

TES  —  Tht  tteurity  tnd  prtetdtnet  DO  ntteh. 

If  ((sv.ite  •  fron  MET.  opt  ions  (to  curl  tyl)  tnd 
(tv.tctutl^rte  •  IronJIET.typtjsfjitririct. prtetdtnet)) 

thtn  rtturn  (TES) 
tlst  rtturn  (MO); 

9.4.6.2.17  Stc#  itttus?  Tht  ttqf.ttttus  function  eonptrts  tht  ttqutnct 
■inbtr  of  tht  inconing  stgMOt  tfsiift  tht  currtnt  rtev  vtritbltt  in  tht 
•tttt  vtctor  to  dtttmint  whtthtr  tht  ttgntnt  eonttins  dots  in  tht  rtev 
rladov.  Tht  dttt  offsets  of  this  function  trt: 

t.  Dttt  SKtttintd  only: 

f  r  onJIET.  s  tg .  st^min  sv.  rtcvjmdw 

•v.rtcvjntxt 

b.  Etturn  vtluts : 

VALID  This  stgntnt  dots  not  conttin  dttt  within 
tht  rtev  window. 

INVALID  This  ttgntnt  DOBS  conttin  dttt  in  tht  rtev 
window. 

•H)ub  to  stro  length  rtev  window  tod  ttro  Itngch  stgntnts, 

—this  dteisioo  fmetion  nust  txtnint  four  ctsts. 

-^htst  ctttt  trt  ttprttttd  in  tht  following  cooditiontl 

sttttnsott. 
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If  (froa  NET.lsngth  •  0) 
thsn  if  Ttv.rtcvjirAdw  •  0) 
thsfi  " 

— Vhsn  ths  ssfaint  cootsioi  no  dsts,  snd  tht  rtctlYS 
— vlndow  If  cloitd,  tht  ttgntot  ttqutnct  nunbtr 
*-aust  tqusl  ths  ntxt  ocptcttd  to  bt  tcctpttblt. 
if  (froa^ntt.ttf ••Odessa  ■  sv.rtcYjntxt) 
thsn  rtturn  (VALID)  ~ 

tlst  rtturn  (INVALID) 

tltt 

-Hfhtn  tht  stgaint  conttlns  no  dots  tod  rtetlvt 
*^ndov  is  opto,  tht  stgasnt  stqutoet  mubtr  aust 
•*ftll  within  ths  rtetift  window, 
if  ((sv.rtcvjntxt  •<  froa  NET.stg.st^nua)  tnd 

(froaJfETTstf.tt^nua  7  sy. rtCY^ntxt^v*  rtcvjtndw) ) 
thtn  rtturn  (VALID)  " 

tlst  rtturn  (INVALID) 

tlst  if  (sY.rtcYjundw  ■  0) 
thsn 

•mhtn  ths  stgasnt  ctrrits  dttt  tnd  tht  rtetiYt 
-^odow  is  elostd,  slthoulh  no  dttt  cto  bt 
*-*«€etptad,  tht  control  inforastion  is  tcctpttblt 
**if  tht  stgasnt  ttqutnct  isiabtr  txtctly  astchts 
—ths  not  sKptettd. 

if  (froa  ntt»stg*8tQ  nun  ■  SY.rtcY  ntxt) 
thtn  rt^rn  (VALID)  * 

tlst  rtturn  (INVALID) 

tlst 

«-4lhtn  tht  stgasnt  ctrrits  dttt  tod  tht  rtetiYt  window 
*-io  opto,  tht  stgasnt  it  tcctpttblt  if  toy  dttt 
-«4tlls  within  ths  rtetiYt  window, 
if 

•—Dots  tht  front  of  tht  dttt  lit  within  tht  window? 
(((sv.rtcY^ntxt  •<  froaJKT.stg.stq^nin) 
tnd  (froJiCT.stg.ttq^lMa  < 
sv.  rtCY^o7xt>SY.  rtCYjsndw) ) 
or  * 

-*Dots  tht  btch  of  tht  dttt  lit  within  tht  window? 
((sY.rtCY^ntxt  •<  froa  NE7.ttg»8t^nua^frooJfET. 

ItngthT 

tnd  (froaJST.ltngthf’froaJIRT.ttg.ttq^aua  < 

"  tY,  rt^^ntxt^t  V.  rtCYjfodw) ) 

or  * 

— ‘Dots  ths  aiddU  of  tht  dots  lit  within  cht  window? 
((sv.rtev^ntxt  >  froa^ntt.stg»st^in>a) 
tnd  (  sv.Ttcv  ntxt^vTrtCYjfodw  < 

( froa  %T.  Itngth^f roaJICT.stg.  st^nua) ) ) ) 
thsn  rtiurn  TvaLID)  ** 

t:st  rtturn  (INVALID) 
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9.A,6.2.18  SYli  on?  Tht  SYN  on  ftACtlon  •xaslnst  tKt  SW  flsg  of  tho 
ineosli^  sofBtntc  Tht  dttt  tfTtets  of  this  fiactloo  art: 

«•  Dots  txaalQtd  only:  fronJIBT.stg*syd_fl«f 

b*  Rtturn  vtluts: 

MO  —  No  STN  Is  prtstnt  In  tht  inconlng  stgntnt* 

TE8  —  A  StN  Is  prtstnt  In  tht  stgaint. 

If  (fronJIET.ttg.synJfXaf  •  HUE) 
thtn  rtt^n  (YES)  * 
tlst  rtturn  (NO) 

9.4.6.2.X9  SYN  in  wn4otT  Tht  STN^lnjmdoi#  function  ditttmlnts  nhtthtr  tn 
Inconlng  stgatnt  contains  a  SYN,  aod**lf**to,  whtthtr  Its  stqutnet  nunbtr  Xlts 
In  t\m  rtcv  window.  Tht  data  tfftcts  of  this  faction  art: 

a.  Data  txaalntd  only: 

fron  NET.sog.syn  flag  st.rtcvjitnt 

fron^lET.  sag.  strain  sv.  rtcwjmdw 

b«  Rtturn  vaXuts : 

NO  No  STN  Is  prtstnt,  or  a  STN  Is  prtstnt  but  It  dots 
not  faXX  In  tht  rtcv  window. 

YES  A  STN  Is  prtstnt  and  fais  in  tht  itcv  window, 

— Afttr  a  eonntctlon  Is  tstabllshtd,  no  stgnsnts  should  contain 
— SYNs.  Rowtvtr,  ctttaln  situations  nay  product  a  SYN. 
-•Shortly  afttr  a  connactloo  optns,  a  dupllcats  of  tht  original 
—SYN  nay  arrltt.  tt  will  not  lit  In  tht  rtcv  window,  having 
—already  batn  accept td.  Or,  during  a  connection  of  long 
—duration,  vary  very  rare  error  conditions  nay  product  a  SYN 
with 

—tht  rtcv  window.  This  sltuatlou  nust  ba  dsttcttd. 

If  ((fronJlET.stg.syn^flag  •  TRUE  )  and 

UroarNET.stg.stq[[oun  >•  sv.rtev^nast)  and 
(frenJlET.stg.st^nun  <  sv.racv^nast  ♦  sv.  rtcvjmdw) ) 

thtn  return  (YES) 
slat  rtturn  (NO); 


9.4.6.2.20  Zero  rtcv  wndow?  Tbs  itro_rtcvjfndow  function  ananlnts  tht 
rtcv  variables  to  dottraint  whether  tht  ?tcv  window  Is  ttro,  preventing  tht 
accaptanot  of  ai^  data  fron  tht  r«Mtt  TCP.  Tht  data  tfftcts  of  this 
function  art: 

a.  Data  «ianintd  only:  sv.rtcvjsndw 
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b.  Rtturn  vslust: 

NO  Tbt  rccv  tflnddv  is  aoc  tcro*  Dtts  esn  be  sccepted* 

tES  —  The  recv  wlodoir  IS  sero*  No  date  csn  be  accepted. 

if  (sv.reevjmdv  •  0) 
then  retuxcTCYES) 
else  return  (NO); 

9 .4 .6 .3  Action  procedures.  The  following  action  procedures  represent  the 
set  of  eetioQC  perfoned  bp  a  TCP  entity  state  aachine.  They  are  called  by 
the  stete  and  event  correspondence  defined  in  Section  9.4.8.  These  proce¬ 
dures  have  been  organised  end  desired  for  clarity  and  are  provided  as  guide¬ 
lines.  Although  tapleaentors  can  reorganise  for  better  perfoiaanee,  the  data 
effects  of  the  resulting  iapleaentations  aust  not  differ  froa  those  specified 
below.  Certain  aspects  of  the  actions  described  in  the  following  procedures 
are  subject  to  design  choices.  Specifically,  rhe  relection  of  strategies  for 
handling  retraosaisslons.  sending  acknowledgaents.  segtanting  data,  accepting 
date  froa  the  reaote  TCP.  and  delivering  date  to  the  ULP  are  governed  by 
iapleaentation  dependent  criterie.  These  strategies  ar»  eneap sole ted  In 
"policy*  procedures  such  as  accept^^licy.  A  policy  procedure  discusses  the 
available  approaches  and  returns  infomation  to  an  action  procedure  indicat¬ 
ing  appropriate  processing.  The  policy  procedures  defined  in  the  following 
section  aret  accspt^oUcy.  aek^oUcy.  deliver^Ucy.  retransalt^licy. 
and  send^^licy.  The  actions  procedures  invoke  the  enecution  environaent 
priaitives.  defined  in  Section  10.  to  pass  aessages  between  protocol  levels 
(TRANSTtt).  to  read  current  tias  (CURRENT  TIKE),  and  to  set  and  cancel  tiasrs 
(SETjriMCR,  CRHCEljriMER). 

9.4.8. 3.1  Oata  aanageasnt  routines.  This  specification  is  intended  to  be 
as  detailed  and  accurate  as  possible without  iaplying  a  particular  iapleasnta- 
tion  approach  or  eorironaent.  Rowever.  e  difficulty  lies  in  the  aanipulation 
of  internal  data  storage  areas  tdiich  is.  by  nature,  iapleaentation  dependent. 
Thus,  e  set  of  data  aanageasnt  routines  are  defined  to  aanipulate  the  gusues 
for  send  and  receive  data  while  specific  data  structures  (such  as  arrays, 
linked  lists,  or  circular  buffers)  reaain  undefined.  The  state  vector  can 
record  end  send  end  receive  veriables  in  terae  of  sequence  nuabers  because 

the  data  routines  correlate  sequence  mabers  to  the  ptgrsical  position  of 
date  within  the  data  structures.  The  data  aanageasnt  routines  defined  in 
the  following  section  ere:  da^add^to^recv.  dajiddjtojiend.  ^.copy^frea^ 
send,  da^reaovt^froajaend.  aod’’da^7eaove^froaJrecvT  ~  -  -  - 

9.4.8.3.2  Accent.  The  accept  action  procedure  accepts  data  froa  the 
incoalng  segasnt  and  places  it  in  the  receive  queue.  The  aaount  of  data 
accepted  is  governed  by  the  iapleaentation  dependent  acceptance  policy. 

An  ACR  is  generated  for  the  accepted  data  according  to  the  ACE  policy  idiich 
is  iapleaentation  dependent.  Also,  scat  data  aay  be  delivered  according  to 
iapleasntation  dependent  delivery  policies. 
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Tht  dsts  sfftets  of  this  proetdurt  srti 
s.  Dsts  cxsalnsd: 

ill  f  isids  iQ  froaJfET  av.rsorjaXoe 


b.  Dsts  aodlfisd: 

sll  fislds  of  toJTET  sv.rtevjradv 

•V.  rsor^iisxt  *  sv.  rscvjpush 

•V.  rsevjirg 

c.  Uesl  usrisblss:  stsrtjisq  saouiit  of  lost 

— ‘Th#  secsptjpoliey  proetdurt  rtturas  hon  ouch 
•^sts  is  to  bs  sectpttd,  its  btginning  stqutiiet  nitbtr. 
--sod  its  loestioo  uitbio  tbs  ineotiog  stgatot* 


scctpt^UcyC  SMUfit,  stsrt.tt^,  offset  ); 

if  (saount  >  0) 
tbsQ 

d«js4djto_jtcr(  stsrt^st^,  svouot,  offset  )} 

— Updstt  the  rtcvjnsst  sequence  miober  if  necesssrp* 
if  (sv.reev  nex?  •  stsrt^seq) 
theo  tv.rec^^nen  )•  stsrt^seq  ^  saouot: 

--teceid  PUSH  sid  UtaHT  infonMition. 
if  (UrosJfCT.seg.pusb^flsg  •  TIDE)  sod 
(sv.reev^ush  <  stsrtjieq  *  soount)) 
tbeo  sv.rece^sb  t*  stsrt^seq  ♦  saouot; 

if  ((frooJflT.seg.urgJlsg  •  TIDE)  sod 

(sv*recv  urg  <  froo^l®T«ssg*s<p^q^nuo  ♦  froo^KET«seg#urgptr) ) 
then  se.recv^urg  *•  frcS[jfET*seg.se^ouo  ♦  froo^HET.seg^urgptrj 

—iefer  to  sck^liep  to  detendne  idiether  so  ACX  should  be 
•s  oersted 
—St  this  point. 

to  sek  sch  poUcrOs 

if"*(to^sek  •  TwE) 

thsn  MndjickC  se.recv^oext  ); 

— tf  the  slUcstion  slloue.  deliuir  dsts  to  the  ULP. 


if  (sv.recv^slloc  >  0) 
then  deliver: 
end: 

f.4.6.3.3  Accent  solicy.  As  one  of  the  policy  procedures.  sccepi^poUcy 
discusses  the  slternstivc  strstegies  for  sccepting  the  dsts  of  iocooing  ssg- 
■sttts  sod  returns  to  the  cel ling  procedure  tht  nieber  of  decs  octets  to  be 
sccepted.  The  persoeters  ere: 
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-  ••qusoet  Bisbur  of  thu  first  octtt  of  dots 
to  bt  secsptod 

b*  ^usotlty  *  tbs  ottobor  of  octots  of  dots  to  bs  oeosptod 

c«  ssfosot  dsts^offstt  •  tbs  pooitioa  of  tbs  first  dots  octst 
vlthln  tSs  la7«BiQ|  ssgosot*#  tsxt  to  bs  seesptsd* 

9«4.6.3.4  Accspt  strstsgy*  A  TC9  laplsssntstlon  WMf  uss  oas  of  ssssrsl 
strstsglss  to  seospt  dots  vltblo  tbs  rscslvs  vlodoit  fros  sa  lacoolsg  ssfasot. 

t.  Accspt  lo-*ordsr  dots  snip*  Tbs  sccsptsocs  tsst  1st 
froi  lfET«ss|«ss^Bis  •  ss«rscv  asait 
Thst  Is,  tCt  ssqusnes  miabsr  of  tbs  TocoBlog  ssgBsnt  aust 
sssetXp  s^usl  tbs  nsKt  sstiBoes  susbsr  sspsctsd  to  bs 
rscslssd. 

b.  Accspt  SCOT  dots  vltblo  tbs  rscslvs  vlsdou.  Tbs  sccsptsoes 
tsst  bss  ssoirsl  psrtst 

sv*rscvjBSit  •<  fraiJRT«sss *00^000 

*  "“  •<  ss*rsev^MSt  ♦  ss.rscsjmdw 

-  or  • 

sv«rsaMssxt  •<  froBjKT»ssi*stv.*^  *  Issftb 

**  •<  iU.rSOMMKt  ♦  SS*rt€SJPBdlf 

Thst  Is,  siQP  portloa  of  tbs  tsst  fslUsg  vltbls  tbs  rscslvs 
wladow  U*s«,  la  tbs  tatsivsl  bstwtsa  tbs  asat  sa^usaes 
auabsr  sxpsctsd  to  bs  rscslvsd  sod  tbs  last  ss^aoacs  mbsr 
la  tbs  tfladow)  Is  seesptsd* 

9.4.4.3.S  *lo»ordsr*  strstsiy*  Tbs  •la-ordsr*  strstsfy  alloas  a  slapls 
scQSptsacs  tsst  sad  a  strslgbtiorvsrd  sebsas  for  dots  storsgs*  Ksasssr,  tbs 
loss  of  s  siagit  ssgasat  caa  rssult  la  tbs  rsaott  TCT  rstrsasalttlsg  sssiy 
succtsdlag  ssgasat*  Tbs  *la*tbs-nriadov*  strategy  rsgulras  a  aero  loaolvsd 
scesptsacs  tsst  sad  a  sopblstlcatsd  data  storagi  sebsas  to  basp  tracb  of 
dots  seesptsd  out  sf  order*  Also,  as  sacb  ssgasat  Is  acosptsd,  tbs  data 
storsgs  aust  bs  ebsebsd  so  tbat  c  coatigusas  latarral  of  sat*of«ordsr  dots 
esa  bs  rscsgaiisd*  This  sirstsgy  allous  tbs  raaott  TCf  U  rstrsssalt  oaly 
lost  ssgassts. 

9*4«4.3*4  Ack  soltcy*  As  oas  sf  tbs  policy  proesdurss.  seb^Uey  discus* 
sss  tbs  sltsrastlus  strstsglss  lor  sckaoulsd^ag  dots  scesptsOroa  laesalag 
ssgasat s  sad  rsturas  to  tbs  eslUsg  actios  proesdurs  s  boolsaa  vslus  tadlcat* 
lag  idfettbsr  sa  scbnoulsdgusat  sbould  bs  seat*  A  TCy  laplsasatstloo  asy  apply 
oat  sf  cue  scbaoulsdgasat  tlalag  sebaass* 

s*  Wbta  dots  Is  acetptad  frsa  roasts  TCF,  laasdlstsly  gsa- 
srsts  as  sapty  ssgasat  coatslalag  currsat  scbasulsdgsasst 
Isfotastioa  sad  rstura  It  to  tbs  rsaots  TCf* 
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b*  When  dsts  is  accepted  from  remote  TCP,  record  the  need  to 
acknowledge  data  in  the  state  vector,  but  wait  for  an  out¬ 
bound  segiimnt  with  data  on  which  to  piggyback  the  ACK, 
However  to  avoid  a  long  delay,  set  an  ack  timer  to  Usdt 
the  delay  to  a  reasonable  Interval*  Thus,  If  no  outboutw'i 
segment  with  data  Is  produced  within  the  chosen  ack  timeout 
Interval,  the  timer  expires  and  an  empty  ACK  segment  Is 
generated  and  sent  to  the  remote  TCP*  If  a  data  segment  Is 
produced  before  the  timer  expires,  the  timer  Is  cancelled 
ami  the  need  to  acknowledge  record  Is  erased  from  the  state 
vector.  (Note  that  no  "ack  timeout’'  event  appears  In  this 
stsRlard*  This  event  and  the  resulting  call  to  the  send^ack 
action  procedure  should  be  added  If  the  this  approach  Is 
taken*) 

The  trade-off  between  the  two  approaches  Is  processing  time  versus  control 
overhead.  The  •automatic"  ack  approach  Is  simple,  but  results  In  «xtra 
segment  generation.  The  -timed"  ack  approach  requires  more  pro^sslng  but 
will  reduce  the  number  of  segments  generated  on  connections  with  t^o-way 
data  transfer* 

9,4. 6. 3*7  Check  urg.  The  checkjirg  action  proce<'iure  examines  the  head?  r 
of  the  Incoming  segment  to  determltTe  whether  new  urgent  Information  Is 
present*  If  so^  rhe  urgent  pointer  Is  recorded  In  the  recv  variables* 

The  data  effects  of  this  procedure  are: 

a*  Data  examined: 

f  r  01  NET*  sag  .urgjlag  f  r  omJIET*  seg .  da  t  a_of  f  se  t 

fromJ**^**«f*«Wtr  fromJIET*  length 

f r om^NET*  seg . teq_oum 

b.  Data  modified:  sv.recv_urg 


begin 

-<heck  urgent  flag  snd  urgent  pointer* 
if  (fromJJET.seg.urg^flag  •  TRUE) 

then  -  -Check  to  see  if  a  new  urgent  pointer  Is  present. 

if  (sv.recv^urg  <  fro«J<J.T.seg.seq_num  +  fromJIET. seg. urgptr ) 
then 

If  (sv.recv  urg  <  sv.recv^save) 

then  —If  the  UL?  Is  not  Tn  "urgent  mode".  It  must  be 
—Informed  of  the  presence  of  urgent  Information. 

— impleaencatlon  dependent  action 
sv,recv  urg  :■  fromJJET.seg.seq^num  ♦  fromJ^ET.seg.urgptrj 

end; 

9. 4. 6. 3. 8  Compuce  checksum.  The  compute_checksum  procedure  computes  tjw 
checkaum  of  an  outbound  segment  and  places  the  value  in  the  header  s  checksum 
field. 

The  data  effects  of  this  function  are: 
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a*  Data  examined 

all  fields  of  to^NET.seg  to^NEl. protocol 

to_JJET*  source^addr  to~NET.  length 

toJ^ET.destlnatlon^addr  * 

b«  Data  modified:  to^NET. a eg. checksum 

begin 

—The  checksum  algorithm  is  the  16-bit  one's  complement  of  the 
—one's  complement  sum  of  all  16-bit  words  in  the  segment 
—header  and  segment  text.  If  a  segment  contains  an  odd  number 
—of  octets,  the  last  octet  is  padded  on  the  right  with  scros 
—to  form  a  16-bit  word  for  checksum  purposes.  While  computing 
— the  checksum,  the  checksum  field  iv«elf  is  replaced  irith  scros. 
—The  checksum  includes  a  96-bit  pseudo  header  prefixed  to  the 
—actual  TCP  header.  As,  the  diagrams  shows,  the  pseudo  header 
—contains  the  source  address,  the  destination  address,  the 
—protocol  identifier,  and  the  length  of  the  TCP  segment 
—(not  counting  the  pseudo  header). 


- - - — 

- 1 - 1 - 1 
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FIGURE  13 •  Compute  checksum  procedure. 

— Thi  actual  computation  is  implementation  dependent, 
end; 

9.4*6.3.9  Conn  open.  The  conn^open  action  procedure  is  called  just  before 
a  connection  enters  the  ESTABLISH^)  state.  According  to  the  implementation 
policy,  the  procedure  updates  the  ACK  and  window  Inforaatlor,  delivers 
any  waiting  data,  and  acknowledges  any  received  data.  The  ULP  is  notified 
of  the  newly  opened  connection  with  an  OPEK_SUCCESS  service  response.  The 
data  effects  of  the  procedure  are:  ~ 

-  Data  examined:  sv.lcn 


-  Data  modified:  toJULP.servlce^rciponse  toJJLP.lcn 

-  Local  variables:  dellvery^amount  need^to^ack 

j  begin 

—Inform  the  ULP. 

toJJLP.service^response  :•  OPEN^SUCGISS; 
tojULP.lcn  :•  7v.lcn;  * 

TR^SFER  toJULP  to  the  ULP  identified  by  sv.source^ort ; 
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— Th«  incoming  segment  contained  either  a  SYN  and  an  ACK  of 
—our  SYN,  or  just  an  ACK.  In  either  case,  use  the  new 
-*ACK  to  update  the  send  variables, 
update; 

—Based  on  Implementation  dependent  policies,  deliver  any  waiting 
—data  to  the  ULP. 

delivery^amount  deliver_^olicy(); 
if  (deli^ry^amount  >  0)  then  deliver; 

—Based  on  implementation  dependent  acking  policy,  ack  the 
—incoming  segment. 

need_to_ack  ack__policy(); 

if  (ne  J^to^ack  -  TRUE)  then  send^ack; 

end; 


9.4.6.3.10  Deliver.  The  deliver  action  procedure  moves  data  accepted  from 
the  remote  TCP  into  the  toJJUP  structure  for  delivery  to  the  ULP.  The  amount 
of  data  delivered  it  based*”on  the  receive  allocation,  the  amount  of  pushed 
data,  and  the  implemsntation  dependent  delivery  policy.  The  data  effects  of 
this  procedure  are: 

a.  Data  eaamined: 

iv. recv_push  sv. recv^next 

sv.recvjirg  sv.recv^finflag 

•  V .  Icn  a V .  sour*ce^^o  rt 


b.  Data  Btdified: 

sv.recvjiave  all  fields  of  toJJLP 

sv.recv"* alloc 

c.  Local  variables:  pushed  delivery^amount  urgent^length 


begin 

—Does  pushed  data  Mit  delivery? 
if  (sv.recv^ush  >  sv.recv  save) 

then  —Pushed  data  waits  so  compute  amount  needing  delivery, 
if  (sv.recv^ush  >  sv.recv^oext) 
then  pushed  :•  sv.recv jit*T  •  av.retiv^^aave 
else  pushed  :•  sv.recv^u*^  sv.recv^save; 

—la  there  enough  allocation  for  all  the  pushed  data? 
if  (sv.recy_^alloc  <  pushed) 
then  deliveTy^amount  :•  sv.recy__alloc 
else  delivery^amount  :*  pushed; 

else  —No  pushed  data  waits.  Refer  to  the  deliver^olicy 
—to  determine  how  much  data  should  be  passed  to  the 
— UIP  at  this  point. 

delivery^smount  :•  deliver_policy( ); 

—.’deliver  computed  amount  of  data  to  ULP,  includit\g  urgent 
—Information. 
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If  (dtflivery^aaount  >0) 
then  begin 

— <heck  for  "end  of  urgent*  in  dete  vhich  cannot  be  delivered 
'—’in  the  sane  delivery  unit  vith  subsequent  non-urgent  data. 

if  ((sv.recvjirg  >  sv.recv^aave)  and 

(sv.recvjurg  <  sv.recvjsave  delivery^aaount)) 

then  — Peliver  the  urgent  data  alone  first, 
begin 

urgent^Iength  :•  sv.recvjurg  -  sv.recv^aave; 

dn_^remove_^fron_^recv(sv.  recv^save ,  urgint^length) ; 
toJJLP.daTa^length  :•  urgenT^length;  "" 

—Note  that  Inplenentation  dependant  delivery  unit 
—site  reotrictions  are  not  handled. 
toJULP.urgent^^flag  TRUE; 
toJUlP.lcn  :•  sv.Xcn; 
toJJLP.service^response  :<•  DELIVER; 

TIU^SFER  toJJlJ  to  the  ULP  naesd  by  to JOLP.  sour  cohort; 

sv.recy^save  ;»  sv.recvjurg; 

8v.recv]\lloc  :«  av^rec^alloc  •  urgent^length; 
deliver^attount  dell^ryjsttount  -  ttr*5»nt^length; 
end;  —  w 

-"Move  data  without  an  end  of  urgent  into  toJULP.data 
—and  deliver  to  ULP.  ** 

dn^reeovejf r oe^recvCsv. recvjsave,  dellvery^aaount ) ; 
to3)LP.da?a_length  ;•  delii^rjjasouDt;  * 

—Note  that^iapleaentation  de^ndent  delivery  unit 
— sist  restrictiona  are  not  handled. 
toJJLP.lcn  sv.lcn; 

IM  sv.  reeves  a  ve  <  sv.recvjurg) 
then  tOjULPTurgcRtJflag  t^^IRUS 
else  toJJLP.urgcnt^flog  PALSE; 

TRANSFER  toJJLF  to  the  UIF  naatd  \r  sv.  sour  escort; 

—Update  reev  variables. 

sv.recVjSave  :•  av.recVjSave  ♦  dallveTyjSeouot; 

sv.rccVjalloc  :•  sv.rec^alloc  -  deliwsTyjaeount; 

—If  the  rsBOte  side  has  closed,  and  this  data  clears  the 
—receive  queue.  Che  ULF  «ust  be  notified, 
if  ((sv.recVjf inflag  •  TRUE)  and 
(sv.recv"’ next  •  sv.recv  saw)) 
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then 

begin 

toJJLP.eeivlce_reeponse  :■  CLOSING: 
to3^«lcn  :■  ev.lcn; 

TRANSFER  to^ULP  to  the  ULP  naaed  by  sv.eource^ort; 
end; 

end;  -*of  data  delivery  to  UIP 
end; 
end; 


9.4.6.3.11  Deliver  policy.  Aa  one  of  the  policy  procedurea»  dellverjolicy 
discuaeea  the  alternative  atrateglea  for  delivering  data  to  the  ULP.  It 
returna  to  the  calling  procedure  the  nieber  of  octets  of  data  to  be  delivered. 
Barring  sero  receive  allocationa  and  pushed  data»  the  TCP  specification  allo%rs 
an  lop  lament  at  ion  to  iellver  data  to  the  ULP  at  Its  ovn  convenience.  However, 
performance  cons Iderat lone  should  be  examined.  On  one  hand,  data  available 
for  delivery  should  be  delivered  with  reasonable  promptness;  it  should  not  be 
delayed  Indefinitely  while  waiting  for  a  delivery  units  worth  to  arrive.  On 
the  other  hand,  the  data  should  not  be  delivered  an  octet  at  a  time  wasting 
both  internal  TCP  processing  tine  and  external  execution  environment  resources. 
A  reasonable  coaproalse  can  be  achieved  guided  by  system  design  criteria. 

9.4.6.3.12  Dispatch.  The  dispatch  action  procedure  accepts  the  data  and 
Interface  parameten  passed  by  tlte  UU*  in  a  send  request,  adds  the  data  to 
the  send  queue,  and  adjusts  appropriate  send  variables.  Depending  on  the 
send  policy,  the  procedure  may  segment  and  transmit  some  portion  of  data  to 
t^it  remote  TCP.  The  data  effects  of  this  procedure  are: 

a.  Data  namined: 

f  rmaJILP  *  Icn  fr  oqJULP  .push^f  lag 

fromJJLP.data  fromJTLP.urge^t^flag 

froaTyiP.data^lef^th  froe^ULP.ulp^tllMOut 

b.  Data  modified: 

sv.seodjfree 
sv.ulp^tlnsout 
sv.seidjiush 
sv.sendjurg 

begin 

«^ave  the  data  along  with  timestamp,  starting  at  sv.send^free, 

-*theo  update  the  send  variables.  "" 

addjrojsendCsv.send^free,  framJDLP.data^length,  CURR£MT^TIHE( )); 

sv.send^free  :•  av.aand^fiae  ♦  frcm^^LP. length; 

If  (froeJDLP.push^f lag  •  ttUS) 
then  sv.sendjpush  :•  sv.aend^free; 


U7 


sv.se  nd^next 

sv.send^una 

sv,ftend*wndw 
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if  ( fronJOLP. urge nt__f lag  ■  TRUE) 
then  sv.seodjurg  :■  sv.send^frte; 

**DependlQg  on  lapleBentation,  the  ULP  tlaeout  tiaer  aiy 
-*-need  to  be  restarted  vhen  the  interval  is  changed  by  the  ULP. 

if  ((frooJJLP.uip_ti»eout  /•  NULL) 

—option  exercised  To  set  tiaeout  and  (froaJULP.ulp^tiaeout  /• 
•v.ulp^tiaeout))  then  sv.ulp^tlaeout  :•  froaJUlP.ulp^tiaeout; 

—Call  the  send^nev^data  procedure  to  determine  if  any 
— ncvly  received  daTa  can  be  aent  at  this  time. 

•eodjnew^data; 

end;  ->«iion-zero  send  vlndov  processing 

end: 


9.4. 6.3. 13  Da  add  to  send.  As  one  of  the  data  aanageaent  routines,  the 
da_add_to_send  procedure  adds  the  data  provided  by  the  ULP  in  froa^ULP.data 
to^the  seik!  storage  area.  The  calling  sequence  is:  ** 

dB_add_to_send(  aeq^nia,  length,  tiae  ) 

eeq^nua  •  the  sequence  maber  of  the  first  octet 
being  added  to  the  storage  area 

length  •  the  luabcr  of  octets  to  be  added 

time  ”  the  current  tlai  to  be  associated  with  each 

data  octet  for  later  derefaination  of  data  age 
for  the  ULP  tiasout. 

9.4.6.3*14  Da  add  to  reev.  As  one  of  the  data  aanageaent  routines,  the 
de_add_to_recv  proce^re  copies  data  from  an  incoming  segaent,  found  in 
froeJiTT. Teg. data,  Into  the  receive  storage  area.  This  routine  is  called 
as  segesnts  are  validated  and  portioria  of  their  data  are  found  to  be  in  the 
receive  window.  The  calling  sequence  is: 

da_add_to_recv(  se^iua,  length,  offset  ) 

seq^nua  ••  the  sequence  nuaber  of  the  first  octet  to  be  copied. 

length  •  the  maber  of  data  octet  to  be  copied. 

offset  •  the  location  of  first  octet  to  be  taken  froa  the 
data  portion  of  the  segmnt. 

9.4.6.3.15  Da  copy  from  send.  As  one  of  the  data  aanageaent  routines, 
the  da^copy^froa^send  proceJufT  copies  data  froa  the  send  storage  arcs  into 
toJIET.stg.data.^  This  routine  is  used  as  data  is  segaented  and  transmitted 
initially,  and  as  retransaissloos  are  required. 

The  calling  sequence  is: 
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da_^copy^fro«jiend(  te^nia,  Itngth  ) 

•e^nuB  ^  the  Mqutnce  aiabtr  of  the  first  date  octet  to  be 
copied  Into  toJiET«eeg»dete 

Urgth  -  the  nuaber  of  octets  to  be  copied 


9.4.6.3.16  Pe  reaove  froB  recv«  As  one  of  the  date  Banagcnent  routines, 
the  dB  reaove  froB  recv  routine  rsBOves  data  froB  tha  receive  storage  area 
and  places  It'^ln  the  toJJLP.data  structure.  This  Is  called  as  data  is 
delivered  to  the  ULP.  The  cslUng  sequence  Is: 

dB^reBOve_^froB_^recv(  seq^nuB,  length  ) 

seqjouB  ■  the  sequence  nuaber  of  the  first  octet  to 
be  reaoved  and  copied 

let«th  •  the  ouBber  of  data  octets  to  bo  reaoved  and  copied 

9.4.6.3.17  Db  reaove  froa  send.  As  one  of  the  data  asnageaent  routines, 

*;he  dB  reaove  froa  send  procedure  deletes  data  froa  the  send  storage  area. 

This  routine  Ts  ciffled  as  data  Is  acknouledged  by  the  reaote  TCF  and  reaoved 
froa  the  retrawal salon  ’queue."  The  calUng  sequence  Is: 

da^reaovt^froa^sendC  se^nua,  length  ) 

•eqjaia  •  the  sequence  tuaber  of  the  first  octet  to  be  reaoved. 
length  •  the  aiaber  of  data  octets  to  he  reaoved. 

9.4.6.3.18  Error.  The  error  procedure  fills  in  the  fields  of  toJJLF  ulth 
the  local  connection  naae,  the  EUU)K  service  response,  and  the  error  description 
passed  by  psraaeter.  This  infocaatloa  Is  passed  to  the  local  ULf. 

a.  Data  exaalned:  sv.lcn  sv.source^porc 

h.  Data  aodifled:  toJ?bF.lcn  toJJlP.servlce^responae 

to"uu. error  desc 


begin 

«<oia truce  an  error  aessage  for  the  local  ULP» 

toJTLP.fervice^responee  :•  AWtOE; 
toJJir  •  Icn  :■  1bv«  Icn; 
to^DUP.error^desc  :•  peraaeter; 

TKANSret  toJJLE  to  the  ULP  aaaed  by  sv.source^rt; 
end;  “ 
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9 ,4, 0.3. 19  Fonnst  net  parstas.  The  totvatjaet^traas  procedure  fills  In 
the  paraiuer.ers  used  by  the  network  protocol  entity  after  the  calling  procedure 
has  filled  '.n  the  9Jtgoing  segoent  header.  The  aixe  of  the  segment  ■  text 
portion  is  pasbed  by  parameter. 

a.  Dat^  exaninad: 

t  o^NET. seg . da  t ajof  feet 

s  vTdes  t  inat  iooji^di  sv.  sour  ce^ad  i  r 

8v.d*stlnation]^ort  sv.source^o^c 

b*  Data  modified: 

toJIET. ident if ier 
to^NET. protocol 
to^HET.  de  s  t  inet  ion_jsddr 
t  o^NET.  s  ag .  sour  cej^rt 
toJJET.  dont^f  ragment 

begin 

—Fill  in  the  ntvcwork  parameters. 

toJvET.scg.source^port  :•  sv.  sour  carport; 

to~NET.9eg.descinatloojp»ort  :•  sv.destination^ort; 

toJIET.sourcc^addr  sv*source^addr: 

to^HET.destiiatioojwldr  :•  sv.  das  t  inat  ionjaddr; 

toJ^T*  protocol  **  :•  TCPJID; 

tc"*HET»type  of  servlet .prtctdenca  •v.actual^rte; 
to3*ET.typa*of]]]]strvict.  reliability  ?•  NOKHAL; 
toJ*ET.typa3oO**^^®**^^2r  l*  ’HOIMAL; 

to^NET*  typa^of^aervlee.  throughput  *•  NOI^KAl.; 
toJiET.ldenTifTar  *•  gan^idO; 

to*MET.dont  fragment  FALSE;  *" 

toJJEI.time^to^Uva  :•  OHE  MHWTEJTTL; 

tp^WET. length  “  *•  te_}{ET.aegTdata_offatt  ♦ 

""  pnramatar;  ” 

to^KET. options [security]  :•  sv.aec; 

end; 

9.4.8.3.20  Can  Id.  The  ganoid  action  procadira  returns  an  Idtntifitr  to 
the  calling  procedure  to  be  peeead  to  the  utcwork  protocol  entity  whan  a 
•tgment  is  transmitted  with  a  NET^SEND  primitive. 

a.  Data  examined:  —implement at  ion  dependent 

b.  Date  modified:  ^•mont 
begin 

—The  generation  of  the  identifier  la  Implemantatloo  dependent. 

—The  network  protocol  entity  uats  the  Identifier »  along  with 
*-'-addrecsing  information,  to  dlftlngulsh  between  aanding  unite 
— (t.t.  datagrama)  if  fragmentation  and  rcaaseably  art  ragcired. 
—So.  7CF  must  ganerate  unique  ident  If  lent  for  each  aagmenr  if 
—the  data  is  to  be  transmitted  without  confusion. 


to_NET.  typejof^strvice 
CORNET,  len^h  ^ 
toJ^ET. source  ad dr 
to"" MET  •  dt  a  t  inat  lon^por  t 
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— *Also,  if  a  rttraoaidcttd  segatat  is  accoap'\nl«<i  by  the 
—identifier  used  for  its  original  traneaiseion,  the  network 
—protocol  entity  aay  be  able  to  piece  together  parts  of  the 
—original  anl  the  retranenleeioo  to  iaprove  its  performance* 
—Note  that  if  repackaging  is  performed  during  retransmission, 
*-the  original  identifier  cannot  be  used, 
end; 

9.4.6.3.11  Gen  isn*  The  gen^isn  procedure  returns  an  initial  sequence 
number  to  the  calling  procedure*~for  use  during  the  three-way  handshake  of 
connection  establishment. 

a.  Data  examined:  —implementation  dependent 

b.  Data  modified:  -  none  - 

— implemf ntation  dependent  action 

9.4«8.3.22  Geo  Icn.  The  pn^lco  procedure  returns  a  local  connection  name, 
or  Ico,  to  the  ealUng  procedurT  to  be  used  as  a  shorthand  identifier  by  TCP 
and  the  local  UL?  in  service  requests  end  responses  pertaining  to  a  connection.^ 

a.  Data  examined:  —implementation  dependent 

Data  modified:  -  none  - 


begin 

—The  generation  of  the  Icn  is  implementation  dependent. 

—A  TCP  entity  usually  supports  many  connections. 

—If  tN  Icn  is  a  pointer  or  table  index,  service  requests 
—can  R  quickly  matched  to  their  state  vector. 

end; 

9.4.6.3«23  Cen  syn.  The  genjsyn  acclon  procedure  formats  and  transmits  a 
segment  containing  a  SW  to  the^remote  TCP.  As  part  of  the  STN  generation, 
an  initial  sequence  cumber  la  selected.  The  procedure  accepts  one  parameter 
whose  values  are  ALONE,  UlTN  ACK,  and  VITK_DATA.  Indicating  whether  the 
segment  will  contain  an  AdC  or  data.  Thls**procedure  dees  not  handle  generating 
a  STK  carrying  a  FTH  flag  because  the  specified  service  Interface  does  not 
support  a  transaction  primitive  descrlb^  In  Appendix  C.  However,  If  such 
primitive  were  created,  this  procedure  would  have  to  be  modified  to  handle 
It.  The  data  effects  of  this  procedure  are: 

a.  Data  exandned: 

sv.source^^rt 
sv.source^addr 
s  V  •  de  s  t  Ins  t  lonj»o  rt 
sv. des  1 1 nat lon^eddr 
sv.recvjwndw  ^ 
sv.send  urg 


sv.recv^lsn 
sv.recv~next 
sv.send^next 
sv.se  nd^free 
sv.ssnd^ush 
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b*  Dsts  aodlflsd: 

•v.tcnd_itn  tv.scnd_ncxt 

sll  flsTds  of  to^NET  ov.ttiid]3uQs 

c.  Local  sorlablot:  saount 


begin 

— Generate  the  initial  sequence  luober  to  be  used  for 
—data  sent  to  the  reaote  TCP. 
sv.send^isn  :■  gen^isnO; 

sv.oendjn<3(t  :•  sv7send__isn  ♦!;  — SYN  uses  the  first  atq#. 
sv.send^una  :■  sy.send^isn; 

toJiET.stg.seq^oua  :•  sv.send^isn; 

—Check  paraaster  to  deteraine  exact  type  of  STN. 
case  paraaeter  of 

when  ALOKE  •> 

toJIET.seg .ack^flag  :■  FALSE; 
tojnsT.seg.vndv  0; 

teJ^T.seg.push^flag:*  FALSE; 
to[KET.sef.ur|^flag  !•  FALSE; 
aaount  :•  0; 

^n  WITH  ACE  •> 

toJifT.seg.ack^flag  :•  TWE; 
toJ^ET.stg.vodv  :•  se.raorjmda; 
to*llEt.sas«aek  aua  :<•  av.reev^ian  ^  1; 
to^lET.stf .pus^  flag  :•  FALSE; 
toJ^I.seg.ur^Tlag  s»  FALSE; 
aaouot  :•  0; 

when  WITM^DATA  •> 

toJlET.seg.aek^flag  :•  FALSE; 
tq^^t.seg.wndw  :•  0; 

—The  data  suppliad  by  the  UU  is  in  the  send  queue. 
—However,  the  aaount  of  data  to  accoapaoy  the  SYK 
—Is  detenilned  by  the  send ^^Ucy. 

aaount  :•  send^^lieyO; 

If  (aaount  >  0) 

then  da^copy^frea^seodC  sv.send^next ,  aaouot  ); 
if~(sv.scf^3^sh  •  sv.seod^ntxi  ♦  aaouot) 
eSeo  tcJIET.seg.push^flag  :•  HUE; 
sv.se  **  sv.s^nd^next  ♦  aaount; 

else  to^HET.seg.push^flag  :•  FALSE; 

end  case; 
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—Add  ths  urftnt  Informstlon  rsfsrdlsss  of  does  Itngth. 
If  (•Y.sond  urg  >•  to  HET,iog,it<^jiu*) 
tbon  to  HETTttg.uri^fTa  <*  TtUB; 

toJ^T.tof.urgptr  :•  sv.Mndjirg  - 
toJIET,  •  Of.  to^Qua; 

•Uo  toJfET«tof«ttr|_fUf  :*  VALSB; 

If  (HAX_SBCMEHTJ512E  option  uotd  In  this  inplontntttlon) 
thon  ~ 

to  UBT.sog.optlonslU  f  2;  — hoodor  slxo 

"  option  kind 

to  IIET.stf.optlonsl2j  i-  4;  —option  longth  • 

“*  4  oetoto 

to  HlT.f#f.optlonsl3.*4l  :•  MAX^SECMEHT^SIZE; 

— Inpl.dop  vsluo 
toJIET*ots.dsto_offsot  ;•  6; 

to^ltBT*oof  •ditojsf  ftot  :•  OfTIOHUvSS^HCADEk; 

f  OHM  tjno  t^rnns  ( Mount ) ; 
eonputo  choeksua; 

TKANSrSE  to  ths  notvotk  protocol  entity, 

ood;  " 

f.*.«.3.24  L<Md  ..eurltr.  Tht  Mcurtty  ftttmttn  (iBeludlm  **e«rlty 
Itvol,  eoaportasntt  trontintslon  control  codoi  ond  HondUng  restrictions)  In 
en  Incoalng  segaent  ere  loaded  Into  the  state  vector. 

The  data  effects  of  this  function  aret 

*  Data  eaaalmjdt 

froa^aetjsptloQs  (security] 

•  Data  aodlfled: 

sv.sec 

••This  vould  only  ocair  after  a  successful  sec^range^astch. 
sv.sec:  •  fronjoet. opt Iona  (security! 

9.4.6. 3.25  Wee  allocatloo.  The  neural location  action  procedure  takes  the 
neu  value  provided  hy  the  OtT  In  en  allocation  service  request  and  adds 
It  to  the  current  receive  alloostloo.  Data  welting  for  this  allocation  is 
delivered  to  the  Dll.  The  data  effects  of  this  procedure  are: 

а.  Data  enaalnedt  fronJIlP.data^Ungth 

б.  Data  sodlfledt  sv.recv  alloc 
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begin 

^-Add  in  the  new  rectlvt  ellocAtion* 

sv.rtcv  elloe  :■  sv.rtcv  nlloc  ♦  froBj)lP*dats_ltngth; 

— Dtpei^li^  on  IspleMtttation  dependent  vindov  ss^enent  stretegy, 
—this  new  receive  allocetlon  aey  be  factored  Into  e  new 
-*velue  for  the  receive  window. 

—If  date  awaits  this  allocation,  deliver  it. 
deliver; 

end; 

9.4.6.3.26  Open.  The  open  action  procedure  records  the  paraaeters  fro*  an 
open  service  request  (either  Active  Open,  Fully  Specified  Fassive  Open,  or 
Unspecified  Passive  Open),  assigns  a  local  connection  naae,  and  returns  it 
to  the  ULP  in  an  OPENJID  service  response.  The  data  effects  of  this  procedure 
arc: 


a.  Data  exaained: 

f  r  oiJUlJP .  r  eq  ut  s  t^nane 

froaJ^LP.  destination^^rt 
f r  oanULP . de  a  t ina t ionjsddr 


b.  Data  nodified: 

sv.aouree^ort 
av.source^addr 
a  V .  de  s  t  inn  ionjport 
sv, dest i net ion^addr 

toJU'LP  •  se  rvice^res  ponse 
to"u  IP .  sour  ce^o  Ft 
to'lllP. source  addr 


f  r  oaJULP .  pre  cede  nee 
f  r  ob*ULP  •  ae  cur  i  ty 
f  r  eenuLP  •  **F_ran|es 
froajULP.tiiie^out 
froa^ULP.claeout  action 


sv. len 

sv.orifinal^prec 
sv.tec,  sv.7ec_ranges 
sv.ulp^tiaaoutT  sv.ULP^tlaeoui 
act  ion 

toJJl^.  destinat  ion^addr 
te*U  LF .  de  s  1 1  na  t  iott^o  rt 
te3^l.F.lcn 


begin 

**Assifn  a  local  connection  naM  according  to 
— inpleaencation  dependent  algorithns. 
sv.Un  :•  gen^lcnO; 

—The  security,  precedence,  and  tinemjt  parsMters  are 
—optional.  If  they  are  not  provided  by  the  UiP,  default 
—values  arc  assigned.  For  security  ond  precedence  defaults 
—in  nonsecure  environaents,  the  lowest  levels  art  generally  used. 
—A  tineout  default  Is  nore  arbitrary,  but  the  current 
^^uggested  value  is  two  alnutes. 

if  (froeJJlP.security  is  present) 
then  sv.sec  :•  froa  ULP. security 
else  sv.sec  :•  tEFAlfLT^SECUIllTt; 
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1£  (fraiJILP.prtctdsnct  is  prsstnt) 

thsQ  •v.’orlginslj^rsc  :•  froaJJlF.prtctdtncii; 

•v.sttusl  prte  s*  froB  UlP.prsctdsnct; 
tlss  sv.ortiltill  prsc  :•  lEFAirLT^PRECEDEHCE; 

sv.setuAl ^#c  1-  DEFAU^T^PRECEDENCE; 

if  (froB  ULP.tiBtout  is  prtssnt) 
thto  sv.ulp  tlBsout  £teBjJtP.tl«B«it 
tlss  sv.ulp^tlasottt  :•  DEFAULT_JIMEOUT ; 

if  (frop  ULPHiatoutjictidn  it  prestnt 

tbsn  sv.lfLP  tiatouC  tction:  •  froB  Ul^*tiBtou traction 

tltt  tv.tJLP“tiatoutjsctioii:  •  DEFAUlT^TllCOUT^sctiott 

— Tht  sourca  port  is  providsd  in  sll  opsn  rsqussts.  Tht  sourct 
•*sddrsss  is  ths  sddrtss  of  this  TCP  sntitj* 
sv«soures  port  :•  froBjffl^.sourct^^^port; 
sv« sourct  sddr  :•  THIS^ADOIRSS; 

—Tht  rBBslnlff  psrsBttttt  vary  according  to  optt  rtqutst  typo, 
cast  froBjnLP.rBqutstjnsis?  of 

vhtn  Unspteifitd  Psssivt  Optn  •> 

—This  roqosst  dots  not  carry  tht  otstinstloo 
— socktt.  It  rtBsins  uBSSSigntd  until  a  Bsrchlng 
— $YN  froB  a  rtBOtt  TCP  srrivts. 
sv«optnj»dt  :•  PASSIVE; 
sv.stcjrsogts:*  £ro»^injP#stc^rsngts; 

uhtn  Full  ?%«slvt  Optn  •> 

sv.disstinstion_sddr  :•  froBjUJP.dtstlnstion^sddr; 
sv.dtstlnstion^oft  *•  froBjJLP.dtsilnstion^pof t; 
sv.optnjvdt  *•  PASSIVE; 
fv.stc^rsngts:*  frBoJUlP.stc^rsngts; 

whtn  Activt  Optfi  •> 

sy.disTlnscloojiddr  ;•  froBj;Lr.dtstlnsil‘»n_sddf ; 
sv, dost Inst lon^port  :•  froB^Ul-P»dtstlnstlon^port; 
sv.optnjsodt  :•  ACTIVE; 

yhtn  Activt  OptnJIlthJDsts  •> 

sy*  dtsT  I  ns  t7e»^  jid  dr  :•  fros  ULf.dtttinstlon^sddr; 
sy.dtftlnstionj^port  :•  frotQ^LF.dtstlnstlon^port; 
sy*optn^aDdt  :•  ACTIVE; 

— Etcord  data  accospanylng  optn 
sayt^stnd^dsta: 

and  ca 
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*-Rtturn  the  loeel  coiiDectloti  nae  ftetlgntd* 


to^UUP.Mrviee^rtepo&ee  t«  OPENJID; 
toJDLF.eour effort  *•  •v.tourct^o^* 
toJ^LF.eouret^addr  :•  te^touree^eddr; 

tv.dtetlaetioQ^ort; 
**  •▼•dtttlnitioB^eddr; 
toJJLP«lcn  :•  ev.len;  "" 


end; 


TRANSFER  toJJlP  to  the  W  Baed  by  ■v.tourctjport; 


9 .4 .6 .3 .27  Opettftll*  The  c^itfell  act  loo  procedure  infoime  the  ULf  that 
the  attapted  connection  could  not  be  opened*  It  ala  clear*  the  atate 
vector.  The  data  effects  of  the  procedure  are: 


a*  Data  eMsined:  av.lcn 
b.  Data  adifiad: 


av.aource^^rt 


all  state  vector  eltant* 

toJ7LP*lca  toJTLP*  aervl  cadres  pea  e 


•^ea truce  an  OPCIM^AIL  aasafe  for  the  DIP* 
toJILP.servica^rtapoae  0P8IMPAXL; 

toJ7LP.lcv'  :•  Tv.lcn;  "" 

TRANSFER  toJ7IJR  to  the  9LF  asad  by  ev.aoura^rt; 


*The  state  actor  ..a  cleared  without  fiaratittf  a  (n*F  aasafe* 
rae  t_self  (NO^RCFOfT)  i 


9.4,6*3*26  Fart  reset*  The  part^reat  actloo  procedua  cleaa  the  and 
and  reev  arlables  without  teaiatTnf  the  conaction*  The  data  affects  of 
the  procedure  are: 


a*  Data  ciaalnud:  sv.epenjvde 

b*  Data  aodified:  all  send  and  receive  variables 


begin 


••The  reaote  TCP  address  and  port  are  cleared  it  the  connection 
—open  node  was  PASSIVE. 

if  (sv.epen^wde  •  PASSIVE) 
then  ** 

sv.destinatiott^rt  :*  NULt; 
sv.destination^addr  :•  If^L; 


•<le*r  all  nuriables  net  during  the  connection  openinf 
—handshake. 

da^renove^f  r oa^se  nd <  s v . a endjuna ,  WUE^S IZE  ) ; 

r  a*~re  e v(  a v .  re  cv~<  re* ,  QUtbE^S X  EE ) ; 


•*.  v_ 


u 


MILITARY  STANDARDS;  TCP 


MIL-STD  1778 


MIL-STD-1778 
12  August  1983 


sv.actual_prec 

:• 

NULL; 

sv.send^next 

:-  NULL; 

sv.recv^lsn 

:• 

NULL; 

sv.sendjuna 

:•  NULL; 

sv.recv^iext 

:• 

NULL; 

sv.send^^ndw 

NULL; 

sv.  recvjindw 

:• 

NULL; 

sv.send^ush 

I-  NULL; 

sv.recv^alloc 

;■ 

NULL; 

sv.se nd^urg 

NULL; 

sv.  reev^ush 

:• 

NULL; 

sv.send^flnflag 

:-  NULL; 

sv.  recvjurg 

!■ 

NULL; 

sv.send^  free 

NULL; 

sv.  reeves  ave 

:• 

NULL; 

sv.send^lastupl 

:-  NULL; 

sv. recv^flnflag 

:■ 

NULL; 

sv.se  nd3astup2 

:-  NULL; 

sv.send^lsn 

:• 

NULL; 

sv.se  nd__maxjieg 

NULL; 

cad; 

9*4«6,3.29  Raise  prec*  The  raise  precedence  action  procedure  raises  the 
precedence  level  recorded  In  the  state  vector  to  the  level  provided  by  the 
reaote  TCP.  paragraph  9.2.11  of  the  entity  overview  discusses  precedence 
negotiation  during  connection  establlshoent.  The  data  effects  of  this 
procedure  are: 

a.  Data  exanlnad:  froBj(ET«typej>f_servlce .precedence 

b.  Data  aodlfled:  sv.actual^prec 

—A  SYN  Iron  the  reaote  TCP  carries  a  precedence  level 
••greater  than  that  Indicated  by  the  local  ’JLP. 
••Precedence  Is  carried  as  a  type  of  service  paraaeter. 
sv.actual^rec  :•  froaJlET.type^of^servlce. precedence; 

9.4.6.3.30  Record  ayn.  The  recordjiyn  action  procedure  records  the 
control  Inforaatlon  from  the  incoolng  segaent  containing  a  SYN  flag. 

The  data  effects  of  this  procedure  are: 


a.  Data  examined:  all  fields  of  froa_NET 

b.  Data  modified: 

sv.recv^next 
sv.recv3irg 
sv.recv^lsn 
s  V .  se  ndjmax^s  eg 
sv.recv  push 

c.  Local  variables:  startjseq 

begin 

—If  this  half  of  the  connection  was  opened  passively*  the 
—remote  Information  should  be  added  to  the  state  vector. 
If  (av.openjmode  ••  PASSIVE) 
then 


sv.send^wndw 
sv.send__una 
sv.destTnatlon^ort 
s V . des  1 1 na t lon^add  r 

amount  offset 


sv.destlnatlon^ort  :»  from^NET.seg.sourcej^ort; 
sv.destlnatloo^^dr  :■  from^NET.source^addr; 
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—Record  recv^dsts. 

sv.recy^lsti  :«  £roo_NET.seg.seq^num; 

•v.recvjnext  :■  sv*recy_^lsiH-l; 

—Record  send  dsts* 

If  (froB_NET.seg.sck_fl«g  •  TRUE) 
then  tv.tendjuns  :■  Troa^^T.seg.ack^mim; 

—Record  Bsxlaua  segnent  else  If  present  In  option  field. 

If  ((froo_NET.seg.dsts_jof fset  >  5)  — optlonless  header  size 

and  (fron^NET.seg. options [0]  -  2))  —Max  Seg  Option  Kind 

then 

sv.send_Baxjieg  :«  froa_KET.seg.optlon[3. .4] ; 

—If  data  accompanied  the  SYN»  apply  the  Implementation 
—dependent  data  acceptance  policy  to  detetmlne  how  much 
—data  should  be  saved »  Its  position  In  the  recyjqueue, 

— ind  Its  position  In  the  Incoming  segment. 

accept_j)ollcy(  start_seq,  amount*  offset  ); 

If  (amount  >0) 


add^to^recvC  start^seq*  amount,  offset  ); 

—Update  the  recv^next  sequence  number  if  necessary. 

If  (sv.recv^^nex't  ■  startjieq) 
then  sv.rec^next  :•  staTt^seq  +  amount; 
else  —record  data  position  In  receive  storage  area 
—implementation  dependent  action 
--Recotd  r’LSH  and  URGENT  Information. 

If  '(fr.'irj;El.seg.push_flag  -  TRUE)  and 
(sv. reev^pufh  <  startjieq  +  amount)) 
ther.  sv.recv  push  :•  starT^seq  amount; 

if  ((fram_NET.seg.urg_llag  -  TRUE;  ais2 

(sv.recv__urg  <  fromJ^ET.seg.ce^num  from^NET.seg.urgptr U 
then  —record  the  new  urgent  dat^  position 

sv.recv_^urg  :■  £rom_JiET,se,t;.seq^rwm  from^NET.seg.urgptr; 


9, *'.,6.3, 31  Report  timeout  (sv  *).  The  repo rt^tlme out  action  procedure 
Informs  the  ULP  that  a  ULP^tlmeout  has  occurred.'"  The  oldest  data  In  the  send 
queue  is  requeued  and  the  timeout  time  reset. 

The  data  effects  of  this  function  are: 

*  'lata  examined: 

**  Date  modified; 
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begin 

€rror(iv__*,  Icn,  *  ULP^tiaeout ) 

trtn*fer”'toJJLP  to  The  ULP  neiies  by  iv^^^eource^jiort; 

requeue^oldest 

end; 

9.4.6.3.32  Requeue  oIde»t  (ev  *).  The  requaue_pldeit  ectlon  procedure 
renoves  the  oldest  dee  froa  the  tendj^ueue  end  requeues  the  dete  neking  it 
the  youngest. 

The  dete  effects  of  this  procedure  ere: 

-  Dete  exealned: 
sv.*send^qutue 

9.4.6.3.33  Reset.  The  reset  ectlon  procedure  foreets  end  sends  e  segnent 
with  e  reset  fleg  to  the  reaote  TCP  to  tenialnete  the  connection.  RESET 
segments  must  be  fonietted  so  thet  the  reaote  TCP  finds  the  segments  eccept- 
eble.  The  procedure  eccepts  one  pereaeter  Indlcetlng  the  foraet  of  the 
RESET  segment  to  be  sent.  The  perimeter  value  "SEG**  Indicates  that  the 
incoming  segment  determines  the  format.  If  the  segment  contains  an  ACK, 
this  forms  the  basis  of  the  sequence  number  In  the  RESET  segment.  If  the 
segment  does  not  contain  an  AHC,  the  RESET  segment  is  made  acceptable  by 
carrying  an  ACK  of  the  incoming  segment's  text*  The  parameter  value  CURRENT 
indicates  that  the  RESET  is  not  the  result  of  an  incoming  segnent,  but 
because  of  a  UIP  abort  request  or  the  UUP  timeout*  In  such  situations,  the 
RESET  segnant  is  formed  with  a  sequence  mmber  based  on  current  state  vector 
values.  The  data  effects  of  this  procedure  are: 

a.  Data  examined: 

sv.source^ort 
sv.source^addr 
sv.  de  s  t  ination^ort 
s V . des  1 1 na t ion^ad  dr 

b.  Data  modified:  -none¬ 
ts  gin 

—Based  on  the  parameter,  set  the  sequence  and  ack  numbers. 

if  (parameter  *  SEC) 

than  —Check  the  incoming  segment  for  ACK  presence, 
if  (frooJIET.seg.ack_flag  •  TRUE) 
then  * 

toJ<ET.seg*seq_num  :»  fron^NET.seg.ack_^num; 

toJIET.seq.ack^flag  :•  FALSE; 

else  ~  ~ 

to_KET.seg.seq_num  :•  0; 
to^NET.seg.ack^flag  :•  TRUE; 
to^NET.seg.ack^num  :•  from^NET.seg.seq^num 

(from  NET. length  -  fTomJ^ET.seg.  data_of  f set^i ) ; 


sv.sec 

sv.actual^prec 
sv.send^next 
sv.recv” next 
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else  -"psmeter  ■  CURRS.HT*  so  use  current  sttte  vector  vslues. 
to  KET.seg.se^nm  :■  sv.send  next; 

to^NET.seq.eckJflsg  J-  PALSE;  “* 


—Fora  e  segaent  using  current  state  vector  date,  set  the 
—reset  flag,  and  transmit  to  the  remote  TCP* 


toJ^ET.seg.  rst^flag 
to_NET, seg • syn^f  lag 
t  o“NET.  s  eg  •  urg[^f  lag 
toJ^ET*  seg.push^f  lag 
to_NET*  seg.f  injf  lag 
to JiET*  seg  .vl  Qdfov 
to~NET* seg .data  offset 


TRUE; 

PALSE; 

PALSE; 

PALSE; 

!•  PALSE; 

:•  0; 

:•  OPTIONLESS  HEATER; 


formatjnet^paramsC  0  ); 
c  oaput^chs  ckaum; 

TRANSFER  to^NET  to  the  network  protocol  entity; 


9.4.6.3.3A  Reset  self*  The  reset^self  action  procedure  informs  the  UUP 
that  the  connection  Is  terminating,  7nd  then  sets  the  state  vector  elements 
to  their  Initial  values*  The  reset^self  procedure  has  one  parameter  lodlcatlng 
the  reason  for  connection  termination*  If  the  parameter  equals  HO^REPORT, 
no  service  response  Is  prepared  for  the  ULP*  All  other  values  produce  service 
responses  Including  RR  for  remote  reset,  HP  for  network  failure,  UT  for  ULP 
timeout,  SP  for  security  or  precedence  alsostch,  UC  for  user  eloae,  and  UA 
for  user  abort*  The  data  effects  of  this  procedure  are: 


a*  Data  examined:  sv*len 


b*  Data  modified:  all  state  vector  elements 


begin 

If  parameter  /•  NOJIEPORT 
then  begin 

case  parameter  of 


when  RA  •> 

to  ULP  .error  desc 
when  HP"* ■> 

toJULP .error  desc 
when  SP”* »>  "* 

toJJLP  •  er  ror^ds  sc 
when  UT  ■> 

to  UU. error  desc 
when  UA“'-> 

to^Ul^  *  errorjdesc 
when  UC*»>  " 

to  UIP .error  desc 
when  SP*” ■> 

toJULP .  errorjdesc 
end  case;  "* 


:■  "Remote  abort** 

:•  "Network  failure*'' 

:•  *Se curl ty/pr seeds nee  mismatch." 

"ULP  timeout* • 

•»  "ULP  abort." 

"ULP  close." 

;•  "Service  failure." 
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to_ULP.lca  !■  tv.lcn; 
to_ULP.servlce^retponse  :■  TEIMINATE; 

TRANSFER  toJJlP  to  the  ULP  Identlfitd  by  iv.touFce^^rt ; 
tnd;  ~ 

— Regardleft  of  the  ettise,  clear  all  queuea  and  Initialite  atate 
vector. 

part_reaet; 

•v.tourct_port  :•  KULL; 

•v.tource^addr  :■  NULL; 
av.deatlnTtionjport  :■  NULL; 
av.deatinatloa^addr  :•  NULL; 
and; 

9.4.6 .3 .35  Reatart  tlac  wait.  The  reatart^tinejialt  action  procedurt 
reatarta  the  currently  running  "time  waif  timer,  “thla  procedure  ia 
called  after  a  retranamitted  FIN  la  aean  from  the  remote  TCP.  The  data 
tffteta  of  thia  procedure  are: 

a.  Data  «aained:  -  none  * 

b.  Data  modified:  -  none  * 

—Cancel  the  exiating  timer  and  atart  it  up  from  acratch. 
cancel  timer (  TIME  WAIT,  av.lcn  ); 
atart Jl*er(  TlHEjlAlT,  av.lcn,  T1KEJ»AXTJMTERVAL  ); 

9.4.6«3.36  Retranamit.  The  retranamit  actiona  procedure  reaenda  data 
that  haa  not  been  acknowledged  within  the  retranamiaaion  timeout  interval. 
Becauae  the  amount  of  data  reaent  ia  implementation  dependent,  thia  deci* 
aion  ia  encapaulated  in  the  retranami  trolley  procedure.  The  data  effect  a 
of  thia  procedure  are: 

a.  Data  examined: 

av.aendjbina 
av.aend^next 
av.aendjpuah 
av.aend^f inflag 
av.recT^next 

b.  Data  modified: 

all  fielda  of  toJlET 
retranamiaaion  timer 

e.  Local  variablea:  retrana_aa»unt  atart^t  puahed^amount 
begin 

— Deteimine  how  much  data  ahould  be  retranamitted  to  the 
—remote  TCP. 

retrana^amount  :•  retranamitj^olicy( ); 


av.aendjrndw 
av.aend^oax^aeg 
av.aendjurg 
av.aend^free 
av.rec7  wndw 


av.lcn  :■  NULL; 
av.aec  :■  NULL; 
av.original_prec  :■  NULL; 
av.actual_prec  NULL; 
av.ulp^timeout  :•  NULL; 
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If  (rctrant^amount  >0) 
then  ~ 

begin 

--StArtlog  froB  the  frost  of  the  retreosaleiioo  queue, 
--tegaent  end  retrenealt  date  indicated  bj  aaount. 

atort__pt  :■  av.aendjuna; 
tqJIET,ieg.aeq_iMn  ~  :•  start^^t; 

toJ^T.teg.ntjflag  :>  FALSE; 

if  (atart^pt  •  av.aciid^isn) 

then  —The  SYN  ia  bei^  retranaaitted. 

to^NET.aeg.ayn^flag  TRUE; 

if  (av.recvjlan  •  NULL)  —Baa  the  reaote  TCP  been  heard  froa? 
then  to_NET7seg«ack_flag  :■  FALSE; 

toJJET.aeg.wndw  :■  0; 

else  toJIET.aeg.ack^mn  :■  av.reor^next; 

toJCET.aeg.ack^flag  :•  TRUE;  * 

toTj^T.teg.vndv  !•  av.recvjvndv; 

if  (KAX^SEGMENT^SIZE  option  used  in  this  iapleBentatlon) 
then  "  “ 

toJ7ET,aeg.optlona[l}  :■  2;  —See  section  6.2.11 

tqJIET»aeg.optiono(2j  :■  4;  —for  option  for«at« 

toJ9ET.aeg.options[3..4]  :•  NAX_SEaMENT_8IZE ; 
to  NET.seg.data  offset  6;  "" 
else  toJiET.seg.dataj>ffaet  !-  OPTI  ONUS  SPREADER; 

else  — Noraal  data  retransaiaslon. 

to JJET.  sag  •  ackjnuB  :  •  av  •  reev^next ; 

toJ^ET.aeg.aciTflag  i*  TRUE; 

toJIET,  aeg .  ayn“* flag  s«  FALSE ; 

to_HET,aeg.data^offaet  s-  OFnONUSSJlEABER; 
toJ^IET  •  aeg  .wndii^  :•  a  v  •  recvj»o7v; 

—Note  that  this  section  aaauaea  that  this  aegaent'a  sise 
—la  less  than  sv.aend^aax^seg'. 

—The  end  of  pushed  data  cannot  be  packaged  vith 
—subsequent  nofrpuahed  data* 

—Prepare  and  traosait  data* 

da^copy^froB^sendC  av.aendjana,  retrana^aaount  ); 

—If  pushed  data  vithin  or  follovlng  data  in  this  segaant, 

— aet  the  PUSH  flag  to  infora  reaote  TCP* 
if  (av*aend  una  ■<  av*send_push) 
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then  to_NET.ssg.push_flsg  TRUE 
else  toJfETtSeg.pustTflsg  :*  FAI.SE; 

ur^at  date  UeT  vlthlo  or  follows  dots  la  this  segtasnt, 
—record  urgent  date  position  In  trader* 

If  (sv*seiidjurg  >  stert^t) 
then  toJTBT.seg.urg^fleg  :•  TWJE; 

toJIET.seg.ur^tr  sv.send^urg  -  stert^pt; 
else  toJ<ET.seg«urg;_fleg  :■  FALSET 
—If  thlT  segaent  contains  that  last  octet  of  data  froa 
—the  ULP,  set  the  FIN  to  Infota  the  remote  TCP. 
if  ((•▼.send^flnflag  ■  TRUE)  and 

(sv.send^freo  ■  atart^t  retransjiaount)) 
then  toJ^T.Teg.fin^flag  :•  TRUE 
else  toYlET.seg.fln^flag  FALSE; 

foraatjnet_paranu(  retrana^^aaount  ); 
eoaput  ejchecksua; 

TRANSFER  toJIET  to  ttie  network  protocol  entity; 

end;  —of  pTeparatlon  and  retransmission  of  •inpushed  data. 

end; 

9.4.6.3.37  Retransalt  policy.  As  one  of  the  policy  procedures,  retransalt^ 
policy  discusses  the  alternative  strategies  for  retransalsalons.  It  returns 
to  the  calling  action  procedure  the  isiabcr  of  octets  to  be  retransaltted. 

A  TCP  lapleaentatlon  aay  employ  one  of  se^ral  retransalsslon  strategies. 

a.  First  only  retransalsslon  -  Halntaln  one  retrata mission 
tlasr  for  the  entire  ^ueue.  When  the  retransalsslon  tlaer 
expires,  send  the  segaent  at  the  front  of  the  retransals* 

Sion  queue.  Initialise  the  tlasr. 

b.  Batch  retransalsslon  *  Malutaln  one  retransalsslon  tlaer 
for  the  entire  queue.  Wheji  the  retransalsslon  tlaer 
expires,  send  all  the  segaents  on  the  retransalsslon 
queue.  Initialise  the  tlasr. 

c.  Individual  retransalsslon  •  Maintain  one  tlaer  for 
each  segment  on  the  retransmission  queue.  As  the  tlaers 
expire,  retransmit  the  segaents  Individually  and  reset 
their  tlaers. 

9.4.6.3.37.1  Retransalsslon  strategy.  The  first  only  retransmission 
strategy  Is  efficient  in  terms  of  traffic  generated  because  only  lost  segsants 
are  retransmitted;  but  the  strategy  can  cause  long  delays.  Th«  batch  rttratu* 
mission  creates  aore  tra^f^c  but  decreases  the  llkellbood  of  long  delays, 
ilewever,  the  actual  effectiveness  of  either  scheme  depends  In  part  on  the 
^ceptance  policy  of  the  receiving  TCP.  For  example,  suppose  a  sending  TCP 
sends  three  segaents,  all  within  the  send  wlr^ow,  to  a  receiving  TCP.  The 
first  segaent  Is  lost  by  the  network.  A  receiving  TCP  using  the  "lo-order** 
scceptance  strategy  discards  the  second  er^  third  segments.  A  receiving  TCP 
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using  the  "In-vlndow**  strategy  accepts  the  sccoud  and  third  sagtMnts,  but 
does  not  acknowledge  or  deliver  any  data  until  the  lost  segnent  arrives. 

Batch  retransaission  fits  better  vith  the  in-order  acceptance  strategy 
because  the  receiving  TCP  has  discarded  all  segaents.  The  sooner  all  three 
segaents  are  retransmitted,  the  better.  First*only  retransmission  fits 
better  with  the  in-window  acceptance  policy  because  only  the  needed  retrans¬ 
mission  occurs  because  the  receiving  TCP  hM  kept  the  segaents  ifithin  its 
receive  window  snd  awaits  only  the  lost  segaent.  The  sending  TCP  aay  also 
choose  to  repackage  segaents  for  retransaission. 

9.4.6.3.38  Save  fin.  The  aave_fln  action  procedure  records  the  presence  of 
a  FIN  flag  in  an  Inccait^  segaent^received  before  a  connection  is  ESTABLISHED. 

The  FIN  is  processed  only  in  the  ESTABLISHED  state.  The  data  effects  of  the 
procedure  are: 

a.  Data  examined:  sv.recv^ncxt 

b.  Data  modified:  av.recvjfin  sv.recv^sh 

— tecord  FIN  is  recy^variable. 
sv.reev^finflag  :•  TBUE; 

sv.recv^ush  :•  sv.recv^nextj  —The  PUSH  function  is  assumed. 

9.4.6.3.39  Save  send  data.  The  save_send_dats  action  procedure  saves  the 
data  provided  by  the  local  ULP  in  a  “Send*  or  an  “Active  Open  with  Data“ 
service  re<iuest  issued  before  the  connection  is  ESTABLISHED.  The  data  effects 
of  the  procedure  are: 


a. 

Data  axaminad  only: 

froiJULP.data 

froaJDLP.  length 

f  r  oaJULF  •  pus  h^f  lag 

f  rcanJLP  •  urgent^ 

b. 

Data  modified: 

sv.send^free 

sv.sendjurg 

begin 

sv.se  nd3u*^ 

to  the  send  queue. 

—Take  the  data  and  add  it 

da^add^to^sendC  sv.send^free,  froaJULP.  length  ); 
sv.aend  free  :•  sv.send^free  ^  frcaJULP. length; 

—Set  the  urgent  and  push  information  as  needed, 
if  (froaJULP.push^flag  •  TRUE) 
then  sv.Tend^ush"":"  sv.send^free; 

if  (froaJJLP.urg^^flag  -  TRUE) 
then  sv.Mnd  urg  :■  sv.send  free; 
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,  9.4.6.3.40  Send  aek.  The  lend^eck  procedure  foraete  end  tends  in  enpty 

b  tegaent  with  the  ACK  value  IndlceTed  by  pereaeter.  The  date  effects  of 

I  this  procedure  ere: 

i 

j  e.  Date  examined: 

•v.oendjnext  av.aource^ort 

tv, recv^ntxt  tv.dettinatlon^port 

tv.actual^rec  tv,  tec 

b*  Data  modified:  all  to^NET,aeg  fields 

I  begin 

I  **The  ACK  field  of  the  segment  It  set  to  the  parafseter  value, 

toJfET,oeg,ack_flag  TRUE; 
to"NET,tef  ,acknDum  :•  parameter; 


-rill  In  the  rest  of  the  tegoent  and  network  parametert. 


toJICT,  teg ,  aeqjnua 
to^HET,  t  eg  >  ra  t_f  lag 
to  J?ET,  teg ,  tyn’^f  lag 
t  o JfCT  .008.  putl^f  lag 
to JfET, teg , f ln_f  lag 
to^NET  •  a  eg ,  da  t^of  f  te  t 
to JIET.  teg  ,wl  nd^tf 


tv, tend  next; 
FALSE;  “ 

FALSE; 

FALSE; 

FALSE; 

OFTIOMLBSSJJEADER; 
tv,  recvj#n7w; 


’—Add  security  and  precedence  InforaatloQ  to  header. 

Add  In  urgent  Information  If  Deeded* 

If  (tv,teni_ur8  >  toJIET.teg.te^num) 
then  ••record  urgenT  data  position  in  header 
to^HET.etg.urg^flag  :•  TRUE; 

toJICT.seg.urgptr  :■  tv,tendjjr8  •  toJiET.teg.teq^nua; 
else  toJfET,teg.urg^flaf  :•  FALSE; 

fonat_net^aramt(  0  ); 
cooput^checktum; 

TKANSFET  to  NET  to  the  network  protocol  entity; 


—Adjust  implementation  dependent  ACK  parametert  such  at 
’—ACK  timer,  or  state  vector  element  for  the  last  ACK'd  octet. 


9,4,6,3,41  Send  fin.  The  tendjfln  action  procedure  records  a  close  request 
and,  if  no  data  it  waiting  to  be  Tranemltted,  formats  and  sends  an  empty 
segment  with  the  FIN  flag  set.  If  data  Is  watting  and  the  window  permits, 
the  FIN  is  sent  along  with  the  data.  The  data  effects  of  this  procedure  are: 

a.  Data  examined:  sv.sendjaext 

b.  Data  modified:  ov,tend^ftnf lag  sv.send^^sh 

•Htecord  the  CLOSE  service  request.  The  CLOSE  Implies  a  PUSH, 
sv,send_flnf lag  :•  TRUE; 
sv,send]^ush  :•  sv.send^next; 
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•-The  FIN  is  stQt  tloQg  with  any  valtlog  data, 
aandjaav^data; 

9.4 .6. 3 .42  Sand  nav  data.  Tha  aandjiairjdata  action  procadura  aKaslnaa 
tha  sand  vlndov,  tha  aaount  of  pushed  dataT  aagaant  alta  rastrletlooa 
uo  dataralna  if  any  Halting  data  can  bt  aant  to  tha  raaota  TCP.  Tha  data 
affects  of  this  procadura  ara: 

a.  Data  axaslnad: 

s  V .  sa  nd jaaxji  ag 

sv.  aourTa^jiort 
•v.dsstlnation^ort 

b.  Data  aodifiad: 

sv.sand^ntxt  sv.sand^uth 

sv.aand^fraa  av.aand^urg 

sv.sand^vndv  all  fiJds  of  toJIET 

c.  Local  variables:  aand^aaount 
begin 

-^Tha  saiount  of  data  to  be  aant  is  dataralnad  by  the 
--sand  vlndov,  tha  aaount  of  data  vaiting,  the  asoust  of 
'-pushed  data»  and  sagaant  alsa  raatrictiona. 

if  ((sv.aand^vndv  /«  0)  and  (av.sand^oaxt  /•  av.aand^fraa)) 
than  bagio’  "  “ 

-*Dsta  can  bs  sent,  but  hov  such? 

**<hack  for  pushed  data,  uhieh  «uat  be  sent  as  soon 

—as  tha  windov  allows, 
begin 

if  (sv.sand ^uah  >  av.aandjnaxt) 
than  —Pushed  data  awaits  Tranaaisaion 

if  (av.aand^uah  <  av.sandjsna  ^  sv.aand^jmdw) 
than  —all  pushed  data  ean'^be  sent 

sand^aawunt  :•  av.aatid ^uah  av.aandjnaxt; 

toJJl/.sag.puahjflag  :•  TtUB;  * 

aUa  — Tend  all  pushed  data  allowed  by  sand  window 

sandjaaount  :•  av.aandjUna  *■  sv.aendjwndw  *  sv.sandjna 
toJTCT.aag.puahjllag  :•  FALSE;  ""  “ 

alsa  —No  pushed  data  waiting.  Nefer  to  send  policy 
—to  dstamlna  aaount  (if  any)  to  be  sent, 
sand  aaow)t  :•  aendjpolicyO; 
tojffT.aag.pushjflaJ  :•  FALSE; 

—How  nuch  data  to  sand  has  bean  dataralnad.  Now 
**-fonsat  and  transalt  tha  sagaant. 
if  (aandjSaount  >0) 
than  begin 


sv.racVjOext 
sv.  recvjrodw 
av.saod"fiaflag 
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to jnT.  •  og,  •o^oua 
to jnCT*  tig  •  ackjDus 
toJIET.  •  tg.  sctTf  lag 
to^NET.  stg  •  tyoTf  log 
toJIET.stg.  rst^f  los 


:■  sv.stod^atxt; 

:■  sv.rocv  next; 
j-  TRUE; 

FALSE; 

:•  FALSE; 

toJfET.itg.dstojoffsot  OPT10NLESS_HEADER; 
toJIET.scg.iflodM  !•  iv.rtcTjradi#; 

tocurltF  and  proctdoncs  to  htsdor. 

**Tho  UUP  mty  hsvo  alroodj  CLOSED.  If  so,  and  this 
Ineludas  tha  last  oetat,  sat  tha  FIN. 

If  ((sv.sand  f inf  lag  ■  TRUE)  and 

Uir.8ai2[_fraa  •  toJIET.sag.sa^nun  4-  sandjsaount)) 
than  to  NET.sa^g.fin  flag  t*  TRUE 
also  to^NET.sag.fioJlag  FALSE; 


if  (sv.saodjurg  >  tO|JIET.sag.sa^m«) 
than  — racold  urgant  data  position  In  haadar 
toJIET.sag.urg^flag  :*  TRUE; 

toYlET.sag.urgptr  :•  sv.sandjars  “  toJIET.sag.sa^nua; 
alsa  toJIET.sag.ur^fXag  s*  FALSE; 

d«^copy_frosMiand(  sv.sandjiaxt,  sand^aaount  ); 
aVTsandToaxt**:-  sv.sand^nalft  ♦  sandj^aaount; 

for«atjiat^airsM(  sand^aaount  ); 
e  oaput^cha  cksua; 

TRANSFE?  toJIET  to  tha  oatvorfc  protocol  antlty; 

-*Oapandlng  on  tha  rctransalsslon  policy  choaao  for 
'-•an  lapltaantatlon,  a  ratransal salon  tlaar 
— aay  oov  naad  to  ba  sat  for  tha  nawly  sant  data, 
•naplaaantatloo  dspandant  action 

and;  '—of  praparatlon  a-id  transalsslon  of  data. 

and: 

and; 


9.4.6.3.43  Sand  policy,  larrlqg  pushad  data  and  saro  racalva  windows, 
tha  TCF  antlty  Is  Mt  to  sagaont  and  transfer  data  at  Its  convanlanca. 

Tha  niabor  of  oetats  chat  should  ba  sane  beginning  at  sv.sand^naxt  Is  ra- 
turnad  to  tha  calling  procadura.  Tha  dafinttlon  of  *coovanlanca*  should  ba 
Influancad  by  dtslgn  goals.  If  tha  prlaary  goal  Is  low  overhead  In  Caras  of 
sagasnt  tinartclon.  than  data  should  ba  accuauLatad  until  a  aaxlnua  segaent's 
worth  (daflnad  by  tha  reaoca  TCP)  la  rasdy.  However ,  If  quick  rtsponsa  Is 
tha  asln  goal,  the  TCF  ant Icy  should  sagasnt  and  transait  data  at  regular 
Intervals  to  alnlaisa  daisy.  Another  aspect  of  the  sand  policy  It  related 
CO  window  aanageasne.  Discussed  In  tha  paragraph  9.2.3 ,  tha  handAlng  of 
saall  sand  windows  aay  altar  sanding  behavior.  Tha  TCP  antlty  aiy  choose  to 
avoid  sanding  Into  saall  windows  (where  saall  Is  defined  as  a  percentage  of 
sagasnt  sUt  or  storage  capacity)  to  achieve  better  throughput. 
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9. 4. f. 3.44  Stt  fin.  Th«  ••t_£ln  actioa  proctdurt  rtcordt  the  prtetncc  of 
f  HK  it  e-t  incoaiort^gaent-  ULP  it  Informed  of  the  remote  ULP*e 
aoSE  eft  r  .  I  date  from  the  remote  ULP  le  delivered.  The  date  effects 
of  this  procedure  ere: 

a.  Del.  examined:  av.recv^aeee  ee.recv^next 

b.  Date  modified:  av.rece^flnflag 
begin 

—Record  the  FIK'a  presence  for  use  In  the  ESTABLISHB)  state, 
sv.recy^flnflag  :•  TRUE; 

■v.recv^ush  :•  sv.recv^next; 

—If  no  data  Is  waiting  to  be  delivered,  a  aoSIHC 
—service  response  Is  Issued  to  Inform  the  local  ULP  of  the 


—remote  ULP*s  aoSE  request. 

If  (sv.recv  save  •  sv.recv  next) 

and  (no"data  is  awaiting  re-ordarlng) 
then 

to  ULP.seivleajresponse  :•  CLOSIMG; 
tolJlP.lcn  :•  sv.lcn; 

nudiSFER  tojaF  to  the  Ulf  named  by  sv.  sour  cavort. 

end: 

9.4.6.3.45  Start  Urn  wait.  The  8tart_tlme_walt  action  procedure  cancels 
all  other  timers  and  sets  tltt  final  "TIHEJIAIT’  timer  lAlch  elicit  time  for 
the  final  FIN  acknowledgment  to  reach  the  rmmote  TCF  before  clearing  the 
state  vector  of  this  connection.  The  data  effects  of  this  procedure  are: 

a.  Data  examined:  -  none  - 

b.  Data  modified:  -  none  * 
begin 

—Issue  timer  cancellation  requests  to  the  execution  envlroosent 
—corresponding  to  all  current  timers. 
cancel  tlmef(  UIP  TIMEOUT  ); 
c.netOlwr(  UTIaNSMIT  ); 

—Sept'rft'*  ea  .trattflM,  ACK  tlMr*  and 

— sero  wlc^ow  tlasrs  may  also  exist. 

—Start  up  thi  tlmejralt  timer  for  the  appropriate  duration— currently 
•<^i>|gested  to  be  2"~mlnutes. 

atan  tli«r(  Tl*  WAIT,  TU«JlAIT_im«VAl.  ); 
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9,4«6.3«46  Updstt>  Tht  up4st#  routlnt  tskss  •  ntv  ACK  fro«  ths  Inco^ng 
§9gmtit  to  updsco  tht  stod  snd  rtctlvo  vsrlsbltt.  Tht  dots  offsets  of  this 
proetdurt  trt: 

t»  Dots  txsaintd: 

frcB  NET.stg.sck^ou*  freeJtTT.stg .window 

f  r  •  •C“ 

b.  Dots  ttodlTlsd: 

sw.stnd  uAt  tw.stnd^wndw 

sv.  soBd"* Ustupl  iw.  stnd^Ustup2 


— TAt  only  now  ACXt,  l.t.  thost  grtsttr  thtn  sw.stndjins. 

If  from  NTT.ttg.tck^nuA  >  sw.stnd^unt 

thtn  btgln  — vpdsTt  tht  rttrsnstlsslou  ^utut 

d»  rtnovt  fro«^stnd(sw.stnd^«t,(fro«  MET.stg.sck^is»  - 
»yTstnljjns));""sv.ttndjins  T*  frotJlET.stf.sck^oon; 

>«*Dtptodli^{  on  rttrsnsslstlon  strstsgyi  tht  rtttsnsnlstlon 
•nlatr  atr  nttd  rtstttlng  boetust  of  tht  now  ACK. 

— lapltatntstlon  dtptndtnt  set Ion 

-•-Tht  rttrtnsnlsslon  tlasout  Intstwtl  my  nttd  sdjustntnt 
—to  sdspt  to  tht  round-ttlp  tint  of  tht  dots  just  ACX-td. 

— lapltnontstion  dsptndtnt  set ion 

—Tht  9tP  tlMiout  tlntr  «ty  nttd  rtstttlng  dut  to  tht 
—tht  succtssfttl  dtllytiT  of  tht  nswly  Aa«td  dtts. 

— lapltatntstlon  dtptndtnt  set Ion 

tnd; 

—A  now  window  Is  proyldtd  If  tlthsr  tht  sttutnet  fstnbtr  of  this 
— stgaint  Is  ntwtr  than  tht  ont  Ust  ustd  to  updstt  tht  window,  or 
—(for  l-wty  dots  trsnsftr)  tht  sttusnet  ninbtr  Is  tht  ssat  ^t 
—tht  ACK  Is  grtttti. 

If  ((tv.stnd  Ustupl  <  frot  WT.stg.st^mia)  or 

(s^.stnd  Ustupl  <  f r onJdET. stg. tch^nun) ) 

thtn  btglo  ^  . 

sv.stisS  wndw  i»  (frotJfKT.stg.tck^oun  ♦  frotJllT*  stg  .window) 
^  •v.ttnd^uas; 

St.  stod  Ustuo.  :•  froa^KKT.stg.stil^iii*; 
st.stnd^Useupl  »•  fron^llET.stg.sck_^»in; 

— itetust  t  ntw  stod  window  hts  srrlttd.  tty  to  stod  dots. 
stndjRtw^dtts; 

tod; 

tnd; 
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10,  EXECUTION  DCVIROtMENT  EEQUZEIMENTS 


10.1  lotroduetioa.  Throughout  this  docuatat,  tht  tavlreaatatil  todsl 
portrsTS  tsch  protocol  tatity  sctipg  as  sa  ladtptadtat  procass.  tflthia  this 
■odtl,  the  exseutloa  tavlronasat  «ist  provlds  tvo  fscllitlts:  later-proesss 
eoBBunlcfitloa  sod  tlslag* 

10.2  Inttr-procsst  eonalcstloa*  Tht  ascutloa  sovlrooBent  aust  provlds 
sn  latsr^procsss  coaaualcstlon  fselllty  to  sasbls  ladsptadsat  proesssts  to 
pass  units  of  lafomstlon,  esllsd  asstsgos.  For  TCP's  purposes,  the  IPC 
fselllty  Is  roqulred  to  prsstnMt  tht  order  of  assssfts*  TCP  uses  the  tPC 
facility  to  azchaags  latsrfact  paraastsfs  aad  data  alth  upper  Uyer  protocols 
across  Its  upper  latsrfscs  sad  the  nscuoik  protocol  across  tht  lowsr  latsrfsct 
Sect  loos  6  and  7  specify  thass  Intsrfacss.  Xo  the  servlet  sad  entity  specif  i* 
cscloac,  this  service  Is  scetssed  through  a  the  folloulag  prlaltlve:  HUNSPER 
*  passes  a  aessage  to  a  oMod  target  proeess. 

^  eaecutloa  eovtroaseat  tMSt  provide  a  tlalag  facility 
that  aalntalns  32*blt  clock  (possibly  fictitious)  with  ivtlts  no  coarser 
then  1  second.  A  process  aust  be  sble  to  set  s  tlasr  for  a  specific  tine 
period  and  be  lof aimed  by  the  esecutloo  eiwiroament  trhea  the  time  period 
hsi  elapsed.  A  process  must  also  be  able  to  cancel  a  previously  set  tlasr. 
Several  TCP  aechanlsas  use  the  timing  facility.  The  positive  ackaowledgacnt 
with  retransaisslon  aechanlsa  uses  tlaem  to  ensure  that  K  data  or  sekaow 
ledgsents  are  lost,  they  ore  re*seat*  The  ULP  timeout  mechanism  uses  the 
timing  facility  to  clock  the  delay  between  data  transmission  and  ackaowladg** 
aent.  The  time«valt  aechanlsa  uses  a  timer  to  allow  enough  time  for  s  final 
FIN  acknowledgeasnt  to  arrive  at  the  remote  TCP  entity  before  cooneccloo 
ceimlnatlon.  Other  u^es  for  s  timing  facility  are  Impleasntstion  dependent* 

In  the  upper  service  and  entity  specif icat ion,  the  timing  services  are 
accessed  with  the  followlag  primitives: 

a.  SET^TlICk  (tlaerjsaae,  tiae_lnterval)  *  allous  a  given  interval  of 
tiiv  and  an  idea?lfier  to  be  opacified.  After  the  specified  la- 
teival  elspse,  sad  timeout  iadlcatlon  and  the  Identifier  is  ra- 
turned  to  the  issuing  process. 

b.  CANCCl.jrilCE  (timerjsane)  -  allows  the  timeout  associated  with 
the  ifntlfisr  to  be  teralnatad. 


c.  CUIttJCKT  TX!C  -  returns  the  current  tlae. 


Custodians: 

Army  -  Ct 
Navy  -  CM 
Air  Force  -  90 

ie\lw  Activities: 

Army  •  SC,  CE.  AD 

Navy  -  AS,  YD.  NC.  OK,  ND,  NC,  EC,  $A 
Air  Force  -  1.  11,  13,  17.  90,  99 


Preparing  Activtcy: 
DCA*UC 

(Project  :FK-0178-02) 


Other  Interest: 

NSA*N$ 

TW-TAC-TT 
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APPENDIX  A.  RETRANSMISSION  STRATEGY  EFFECTIVENESS 

As  noted  in  the  entity  overvleif,  Section  9.2,  s  TCP  iapleaentatlon  nsy  employ 
one  of  several  retransmission  strategies: 

a.  First-only  retraramlsslon  -  A  TCP  maintains  one  retransmission  timer 
for  the  queue,  retransmitting  the  front  segment  (or  segment *8  worth 
of  data)  when  the  timer  expires. 

b.  Batch  retransmission  -  A  TCP  mtlntalns  one  retransmission  timer 
for  the  queue,  retransmitting  all  segments  on  the  queue  when  the 
timer  expires. 

c.  Individual  retransmission  -  A  TCP  maintains  one  timer  per  segment 
on  the  queue,  retransmitting  each  segment  when  Its  Individual  timer 
expires. 

The  first-only  retransmission  strategy  la  efficient  In  terms  of  traffic  generated 
because  only  lost  segments  are  retransmitted;  but  the  strategy  can  cause  long 
delays.  The  batch  retransmission  creates  more  traffic  but  decreases  the 
llkelllttod  of  long  delays.  The  Individual  retransmission  strategy  Is  a 
compromise  between  delay  and  traffic  but  requires  much  more  processing  time 
from  the  TCP  entity.  However,  the  actual  effectiveness  of  each  scheme  depends 
In  part  on  the  acceptance  policy  (paragraph  9.2.4)  of  the  receiving  TCP. 

For  example,  suppose  a  sending  TCP  sends  three  segments,  all  within  the  send 
window,  to  a  receiving  TCP.  The  first  segment  Is  lost  by  the  network.  A 
receiving  TCP  using  the  "In-order*  acceptance  strategy  discards  the  second 
am  third  segments.  A  receiving  TCP  using  the  "In-wlndow"  strategy  accepts 
the  second  and  third  segments,  but  docs  not  acknowledge  or  deliver  any  data 
until  the  Intervening  segment  arrives. 

latch  retrinsmlsslon  performs  better  with  the  In-order  acceptance  strategy 
because  the  receiving  TCP  has  discarded  all  segments.  All  three  segments 
must  be  retransmitted— the  sooner  the  better.  First-only  retransmission 
performs  better  with  the  itmrlndow  acceptance  policy  because  only  the  neces¬ 
sary  retransmissions  occur  since  the  receiving  TCP  has  kept  the  segments 
within  Its  receive  window  and  awaits  only  the  lost  segment. 

Unfortunately,  a  sending  TCP  cannot  know  what  acceptance  policy  Is  being 
used  by  the  receiving  TCP.  Instead,  the  retransmission  strategy  must  be 
chosen  according  to  Implementation  dependent  and  configuration  dependent 

design  goals. 
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APPENDIX  B.  DYNAMIC  RETRANSMISSION  TIMER  CX)MPUTATION 

Because  of  the  variability  of  the  networks  that  coapose  the  internetwork 
systea  and  the  vide  range  of  uses  of  TCP  connections,  the  retraisoission 
tineout  should  be  dynamically  determiued*  One  procedure  for  determining  a 
retransmission  time  out  is  given  here  as  an  illustration. 

Measure  the  elapsed  time  between  sending  a  data  octet  with  a  particular 
sequence  aimber  and  receiving  an  acknowledgment  that  covers  that  sequence 
number  (Segments  sent  do  not  have  to  match  segments  received).  This  meas¬ 
ured  elapsed  time  is  the  Round  Trip  Time.  Next,  compute  a  Smoothed  Round 
Trip  Tiae  (SRTT)  as: 

SRTT  -  (  ALPHA  *  SRTT)  +  ((1-ALPHA)  *  RTT) 
and  based  on  this,  compute  the  retransmission  timeout  (RTO)  as: 

RTO  -  fflinimum(UBOUND,  maximum(LBOUND,(BETA*SRTT))) 
where: 

UNBOUND  ■  an  upper  bound  on  the  timeout  (a.g. ,  1  minute) 

LBOUND  -  a  lower  bound  on  the  timeout  (e.g. ,  1  second) 

ALPHA  ■  a  smoothing  factor  (e.g.,  .8  to  .9) 

BETA  "  a  delay  variance  factor  (e.g.,  1.3  to  2.0) 
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appendix  C.  ALTEmriVES  IN  SERVICE  INTERFACE  PRIMITIVES 

The  service  primitives  offered  to  the  upper  level  protocol  are  specified  in 
paragraph  6.2.  The  service  request  primitives  are: 


-  Unspecified  Passive  Open, 

-  Fully  Specified  Passive  Open, 

-  Active  Open, 

-  Active  Open  with  Data, 

-  Send, 

-  Allocate, 

-  Status, 

-  Close,  and 

-  Abort 


The*.  prl«itlve»  .upport  the  mlnlm.1  iervicet  required  of  e  TCP. 
comhlnatlone  or  modif Icetlone  aey  offer  ^Idltlonel  eervlcei  that  are  tailored 
to  the  roqulreBents  of  a  particular  tat  of  upper  Uvel  protocolt.  Several 
examples  are  provided  belov. 

If  the  protocol  tupportlng  TCP  It  the  Inteniet  Protocol  and  a  TCP  Inpleaiente- 
tlon  wlthet  to  export  IP’t  option  tervlcet  (Including  tource  routing,  racord 
routlis,  ttreta  Identification  and  tlnettaapt),  an  addtlonal  optlont  param¬ 
eter  would  be  required  In  all  Open  and  Send  tervlce  requeatt. 

An  upper  level  protocol  -y  need  a  rellabU  tranaactlon  tervlce.  That  la,  a 
ULP  may  wish  to  open  a  connection,  send  a  single  message,  and  tt^n  close  the 
IJrnn^lon!  To  aTceaa  thla  tervlce.  the  apeclfled 

the  ULP  to  issue  at  least  two  service  primitives,  an  Open  ^th  Data  and  a 
Close,  to  eacerdse  this  service.  A  TCP  may  be  designed  with  a  service 
primitive  that  combined  the  Open  and  Close  to  form  a  new  primitive,  called 
^rhaps  Transaction,  which  would  include  all  the  Open  parameters,  the  ^ta 
to  be^transmitted,  and  the  signU  to  close  the  connection  after  data  delivery. 

The  upper  Uyer  seivice  definition  (paragraph  6.3)  does 

Open  request  to  be  followed  by  an  Active  Open  request.  Instead,  the  ULP 

first  issue  a  Close  or  Abort  request  to  cancel  the  Passive  Open  request, 
then  issue  an  Active  Open  request.  A  TCP  wy  h«  designed  to  allw  c^^t- 
Sion"  of  open  requests  from  passive  to  active.  In  this  Mse,  a  ULP  cwld 
issue  a  Full  Passive  Open  request  followed  by  an  Active  Open  or  a  Send 
request  to  actively  initiate  a  connection.  Thus,  the  local  entity 
dUpt.  (Lpe.rlng  in  p.r.gr.ph  6.4)  eh.ng..  to  Inelud.  .  tr.n.ltlon  fro.  th. 
PASSIVE  to  the  ACTIVE  state  as  shown  in  Figure  15. 
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FOREWORD 

This  document  specifies  the  File  Transfer  Protocol  (FTP)  which  supports 
the  transfer  of  file  data  throughout  a  heterogeneous  host  computer 
network.  This  draft  standard  defines  the  FTP*s  role  and  purpose,  defines 
the  services  provided  to  users  and  specifies  the  mechanisms  needed  to 
support  these  services. 
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1.  SCOPE 

1.1  Purpost.  This  standard  establishes  criteria  for  the  File  Transfer 
Protocol  (FTP)  used  for  tranf erring  files  between  cooputer  rystea». 

1.2  Orqanization.  This  standard  introduces  the  File  Transfer  Protocol's 
role  and  purpo'seTHtflnes  the  services  provided  to  users*  and  specifies  the 
Mechanism  needed  to  support  those  services. 

1.3  toolication.  The  File  Transfer  Protocol  is  approved  for  iaplemntation 
in  hosts  of  0*11  DoO  packet  switching  networks  which  connect  or  have  the  poten¬ 
tial  for  utilizing  connectivity  across  network  and  subnetwork  boundaries  and 
which  require  a  file  transfer  service.  The  tern  network  as  used  herein  in¬ 
cludes  local  Area  Networks. 

1.4  Objectives.  The  objectives  of  FTP  are  1)  to  pronote  sharing  of  files 

(coaputer  prograas  and/or  data)*  2)  to  encourage  indirect  or  iMplfcit  (via 
progriK)  um  of  r«wt*  coaputtrs»  3)  to  t  ustr  fro*  vorlotion*  In  flit 

stOTMi  SMtwt  MOflt  Hosts,  Mid  4)  to  trwisftr  dtta  rtlltbly  and  tffl- 
clantiy.  FTP,  thougn  usabit  dirtctly  by  a  uMr  at  a  ttnrtnal.  Is  dtsignad 
Mlnly  for  ust  by  prograas.  Tht  attaapt  In  this  spoclftcatlon  Is  to  satisfy 
tht  dirtrs*  ntfds  of  coaputtr  ustrs,  with  a  sitpla  and  aaslly  ItpItMnttd 
protocol  design.  This  standard  assuMS  knotladge  of  Transalsslon  Control 
Protocol.  HIL-STO-1778,  and  TILWT  Protxol,  HIL-ST0-17M. 
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2.  REFERENCED  DOCUNENTS 

2.1  Issues  of  docuwewts>  ihe  felloMing  Oocuwnts  of  the  Issue  In  effect  on 
date  of^VKlation  for  bids  or  request  for  proposal,  font  a  part  of  this 
standard  to  the  extent  specified  herein.  (The  provisions  of  this  paragraph 
are  under  consideration.) 

Standards: 


Federal 


FEO-STD-1037 


Nllltary 


Ha-$TD^1778 

HIL-STD-17C2 


Glossary  of  TelecoMRmlcatlons  Teras 


Transalsslon  Control  Protocol 
TELNET  Protocol 


2.2  Other  publications.  The  follovlng  docuaents  fora  a  part  of  this  stan* 
dard  to  ike  exiwt  specified  herein.  Unless  otherwise  Indicated,  the  issue  In 
effect  on  date  of  Invitation  for  bids  or  request  for  proposal  shall  apply. 

(The  provisions  of  this  paragraph  are  under  consideration.) 
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s.  Sferver^PL  The  protocol  Interpreter  ’‘listens*’  on  Port  L  for  a 
connection  from  a  user-PI  and  establishes  a  TELNET  communication 
connection.  It  receives  standard  FTP  commands  from  the  user-PI, 
sends  replies,  and  governs  the  server-DTP. 

t.  TELNET  connections.  The  full-duplex  communication  path  between  a 
user-PI  and  a  server-PI,  operating  according  to  the  TELNET 
Protocol . 

u.  Type.  The  data  representation  type  used  for  data  transfer  and 
storage.  Type  implies  certain  transformations  between  the  time  of 
data  storage  and  data  transfer.  The  representation  types  defined 
In  FTP  are  described  in  the  Section  on  Establishing  Data 
Connections. 

V.  User-DTP.  The  data  transfer  process  "listens"  on  the  data  port  for 
a  connection  from  a  server-FTP  process.  If  two  servers  are 
transferring  data  between  them,  the  user-DTP  is  inactive. 

w.  User-FTP  process.  A  set  of  functions  including  a  protocol  inter- 
preter,  a  data  transfer  process  and  a  user  interface  which  together 
perform  the  function  of  file  transfer  in  cooperation  with  one  or 
more  server-FTP  processes.  The  user  interface  allows  a  loca; 
language  to  be  used  In  the  command-reply  dialogue  with  the  user. 

X,  User*PI.  The  protocol  Interpreter  initiates  the  command  connection 
from  its  port  U  to  the  server-FTP  process,  initiates  FTP  commands, 
and  governs  the  user-DTP  if  that  process  is  part  of  the  file 
transfer. 
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4.  GENERAL  REQUIREMENTS 

specifying  a  File  Transfer  Protocol  it  is  desirable  not  to 
assume  a  set  system  configuration.  As  a  practical  matter,  the  distributions 
of  the  file  transfer  protocol  will  vary  with  specific  hardware 
configurations.  Although  appearing  to  focus  on  FTP  implementations,  this 
standard  can  apply  to  any  configuration  given  appropriate  protocols  to  bridge 
hardware  boundaries.  An  example  of  where  FTP  is  configured  ifi  a  host  protocol 
hierarchy  can  be  seen  in  Figure  1. 


FIGURE  1.  Example  FTP  configuration  in  a  host  protocol  hierarchy. 

^•2  The  FTP  model.  The  following  mcdel  (see  Figure  Z)  may  be  diagramned 
for  an  fip  service. 


•wvm-nr  utan^ 

NOTES:  1.  The  data  connection  may  be  used  in  either  direction. 
2.  The  data  connection  need  not  exist  all  of  the  time. 

FIGURE  2.  Model  for  FTP  use. 
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3.  DEFINITIONS 

3.1  Definition  oT  terms.  The  definition  of  terms  used  in  this  standard 
shall  comply  wUh  FED-StO-T037.  Terms  and  definitions  unique  to  MIL-STD-1780 
are  contained  herein. 

Byte  size.  There  are  two  byte  sizes  of  interest  in  FTP;  the 
logical  byte  size  of  the  file,  and  the  transfer  byte  size  used  for 
the  transmission  of  the  data.  The  transfer  byte  size  is  always  6 
bits.  The  transfer  byte  size  is  not  necessarily  the  byte  size  in 
which  data  is  to  be  stored  in  a  system,  nor  the  logical  byte  size 
for  interpretation  of  the  structure  of  the  data. 

b.  Command  Connection.  A  TELNET  connection  in  which  FTP  commands  and 
rephes  are  exchanged  between  the  user  and  server  FTP  processes, 
respectively.  Although  the  degree  to  which  the  TELNET  protocol  is 
utilized  is  not  specified,  both  user  and  server  processes  must  have 
the  capability  to  participate  in  TELNET  negotiations.  (The  default 
port  for  the  command  connection  is  defined  as  Port  L.) 

Data  connection.  A  simplex  connection  over  which  data  is  trans- 
f erred,  in  a  specified  mode  and  type.  The  data  transferred  may  be  a 
part  of  a  file,  an  entire  file  or  a  number  of  files.  The  path  may 
be  between  a  server-OTP  and  a  user-OTP,  or  between  two  server-OTPs, 

Data  port.  The  passive  data  transfer  process  "listens*  on  the  data 
port  for  a  connection  from  the  active  transfer  process  in  order  to 
open  the  data  connection. 

e«  EOF.  The  end-of-file  condition  that  defines  the  end  of  a  file 
B^ng  transferred. 

f.  EOR.  The  end-of*-record  condition  that  defines  the  end  of  a  record 
Being  transferred. 

9«  Hr ror  recovery.  A  procedure  that  allows  a  user  to  recover  from 
certain  errors  such  as  failure  of  either  Kjst  system  or  transfer 
process.  In  FTP,  error  recovery  may  involve  restarting  a  file 
transfer  at  a  given  checkpoint. 

FTP  commands.  A  set  of  commands  that  comprise  the  control  infer- 
mat ion  flowing  from  the  user-FTP  to  the  server-FTP  process. 

i*  File.  An  ordered  set  of  computer  data  (including  programs),  of 
arbitrary  length,  uniquely  identified  by  a  pathname. 
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Mode.  The  mode  in  which  data  is  to  be  transferred  via  the  data 
connection.  The  mode  defines  the  data  format  during  transfer  in¬ 
cluding  EOR  and  EOF.  The  transfer  modes  defined  in  FTP  are 
described  in  the  Section  on  Transmission  Modes. 

k.  NVT.  The  Network  Virtual  Terminal  as  defined  in  the  TELNET 
Protocol  (paragraph  4.2.1,  MIL-STD-1782.) 

l.  NVFS.  The  Network  Virtual  File  System.  A  concept  which  defines  a 
standard  network  file  system  with  standard  commands  and  pathname 
conventions.  FTP  only  partially  implements  the  NVFS  concept  at 
this  time. 

m.  Page.  A  file  may  be  structured  as  a  set  of  independent  parts 
caned  pages.  FTP  supports  the  transmission  of  discontinuous  files 
as  Independent  indexed  pages. 

n.  Pathname.  Pathname  is  defined  to  be  the  character  string  which 
must  be  input  to  a  file  system  by  a  user  in  order  to  identify  a 
file.  Pathname  normally  contains  device  and/or  directory  names, 
and  file  name  specification.  FTP  does  not  yet  specify  a  standard 
pathname  convention.  Each  user  must  follow  the  file  naming 
conventions  of  the  file  systems  Involved  in  the  transfer. 

0.  Record.  A  sequential  file  may  be  structured  as  a  number  of 

conTTguous  parts  called  records.  Record  structures  are  supported 
by  FTP  but  a  file  need  not  have  record  structure. 

p.  Reply.  A  reply  is  an  acknowledgment  (positive  or  negative)  sent 
from  server  to  user  via  the  command  connections  in  response  to  FTP 
commands.  The  general  form  of  a  reply  is  a  completion  code 
(including  error  codes)  followed  by  a  text  string.  The  codes  are 
for  use  by  programs  and  the  text  is  usually  Intended  for  human 
users. 

9*  Server-QTP,  The  data  transfer  process,  in  its  normal  "active" 
state,  establishes  the  data  connection  with  the  "listening"  data 
port,  sets  up  parameters  for  transfer  and  storage,  and  transfers 
data  on  command  from  its  PI.  The  OTP  can  be  placed  in  a  "passive" 
state  to  listen  for,  rather  than  initiate,  a  connection  on  the  data 
port. 

r.  Server-FTP  process.  A  process  or  set  of  processes  which  perform 
tTie  funcTion  of  ^ile  transfer  in  cooperation  with  a  user-fTP 
process  and,  possibly,  another  server.  The  functions  consist  of  a 
protocol  interpreter  (PI)  and  a  data  transfer  process  (DTP), 
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4.2.1  Cownand  initiation.  In  Figure  2,  the  user^jrotocol  interpreter 
initiates  the  command  connection.  At  the  initiation  of  the  user,  standard  FTP 
conmands  are  generated  by  the  user-PI  and  transmitted  to  the  server  process 
via  the  connand  connection.  (The  user  may  establish  a  direct  command  connec¬ 
tion  to  the  server-FTP,  from  a  TAG  terminal  for  example,  and  generate  standard 
FTP  commands  himself,  bypassing  the  user-FTP  process.)  Standard  replies  are 
sent  from  the  server-PI  to  the  user-PI  over  the  command  connection  in  response 
to  the  conmands. 

4.3  FTP  data  connections.  The  FTP  conmands  specify  the  parameters  for  the 
data  connection  (data  port,  transfer  mode,  representation  type,  and  struc¬ 
ture)  and  the  nature  of  file  system  operation  (store,  retrieve,  append, 
delete,  etc.).  The  user-OTP  or  its  designate  should  "listen"  on  the  specified 
data  port,  and  the  server  initiate  the  data  connection  and  data  transfer  in 
accordance  with  the  specified  parameters*  It  should  be  noted  that  the  data 
port  need  not  be  in  the  same  Host  that  Initiates  the  FTP  conmands  via  the 
command  connection,  but  the  user  or  the  user-FTP  process  must  ensure  a 
"listen"  on  the  specified  data  port.  It  should  also  be  noted  that  the  data 
connection  may  be  used  for  simultaneous  sending  and  receiving.  In  another 
situation,  a  user  might  wish  to  transfer  files  between  two  Hosts,  neither  of 
which  is  his  local  Host.  He  sets  up  conmand  connections  to  the  two  servers 
and  then  arranges  for  a  data  connection  between  them.  In  this  manner  control 
information  is  passed  to  the  user-PI  but  data  is  transferred  between  the 
server  data  transfer  processes.  Figure  3  is  a  model  of  this  server-server 
interaction. 


4.3.1  Command  connections .  The  protocol  requires  that  the  command  connec¬ 
tions  be  open  while  data  transfer  is  in  progress.  It  is  the  responsibility  of 
the  user  to  request  the  closing  of  the  command  connections  when  finished  using 
the  FTP  service,  while  it  is  the  server  who  takes  the  action.  The  server  may 
abort  data  transfer  if  the  conmand  connections  are  closed  without  command. 
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4.4  Data  transfer  functions.  Files  are  transferred  only  via  the  data 
connectlofu  The  comnand  connection  Is  used  for  the  transfer  of  coiMiand$» 
which  describe  the  functions  to  be  performed,  and  the  replies  to  these 
commands  (see  the  Section  on  FTP  Replies).  Several  commands  are  concerned 
with  the  transfer  of  data  between  Hosts.  These  data  transfer  commands  Include 
the  MODE  command  which  specify  how  the  bits  of  the  data  are  to  be  trans¬ 
mitted,  and  the  STRUcture  and  TYPE  commands,  which  are  used  to  define  the  way 
In  which  the  data  are  to  be  represented.  The  transmission  and  representation 
are  basically  Independent  but  "Stream”  transmission  mode  Is  dependent  on  the 
file  structure  attribute  and  If  "Compressed"  transmission  mode  Is  used  the 
nature  of  the  filler  byte  depends  on  the  representation  type. 
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5.  DATA  REPRESENTATION  AND  STORAGE 

5.1  Data  representation  differences.  Data  Is  transferred  from  a  storage 
device  in  the  sending  ^st  to  a  storage  device  In  the  receiving  Host.  Often 
It  Is  necessary  to  perform  certain  transformations  on  the  data  because  data 
storage  representations  In  the  two  systems  are  different.  For  example,  NVT- 
ASCII  has  different  data  storage  representations  In  different  systems.  A 
computer  may  store  NVT-ASCII  as  five  7-b1t  ASCII  characters,  left-justified  In 
a  36-b1t  word.  Another  system  may  store  NVT-ASCII  as  8-b1t  EBCDIC  codes.  It 
may  be  desirable  to  convert  characters  Into  the  standard  NVT-ASCII  representa¬ 
tion  when  transmitting  text  between  dissimilar  systems.  The  sending  and 
receiving  sites  would  have  to  perform  the  necessary  transformations  between 
the  standard  representation  and  their  Internal  representations. 

5.1.1  Data  representation  In  binary.  A  different  problem  in  representation 
arises  when  transmitting  binary  data  (not  character  codes)  between  Host  sys¬ 
tems  with  different  word  lengths.  It  Is  not  always  clear  how  the  sender 
should  send  data,  and  the  receiver  store  It.  For  example,  when  transmitting 
32-451 t  bytes  from  a  32-bit  word-length  system  to  a  36-bit  word-length  system. 
It  may  be  desirable  (for  reasons  of  efficiency  and  usefulness)  to  store  the 
32-b1t  bytes  right-justified  In  a  36-bit  word  In  the  latter  system.  In  any 
case,  the  user  should  have  the  option  of  specifying  data  representation  and 
transformation  functions.  It  should  be  noted  that  FTP  provides  for  very 
limited  data  type  representations.  Transformations  desired  beyond  this 
limited  capability  should  be  performed  by  the  user  directly. 

5.2  Data  representation  types.  Data  representations  are  handled  In  FTP  by 
a  user  spec ^ Tying  a  representation  type.  This  type  may  implicitly  (as  In 
ASCII  or  EBCDIC)  or  explicitly  (as  In  Local  byte)  define  a  byte  size  for 
Interpretation  which  is  referred  to  as  the  "logical  byte  size."  This  has 
nothing  to  do  with  the  byte  size  used  for  transmission  over  the  data  connec¬ 
tion,  called  the  "transfer  byte  size",  and  the  two  should  not  be  confused. 

For  example,  NVT-ASCII  has  a  logical  byte  size  of  8  bits.  If  the  type  is 
Local  byte,  then  the  TYPE  command  has  an  obligatory  second  parameter  speci¬ 
fying  the  logical  byte  size.  The  transfer  byte  size  is  always  8  bits.  The 
types  ASCII  and  EBCDIC  also  take  a  second  (optional)  parameter;  this  is  to 
Indicate  what  kind  of  vertical  format  control,  if  any,  is  associated  with  a 
file*  The  data  representation  types  are  defined  in  paragraphs  5.2.1  and 
5.2.2. 


ASCII  format.  This  is  the  default  type  and  must  be  accepted  by  all 
FTP  implementations.  It  is  intended  primarily  for  the  transfer  of  text  files, 
except  when  both  Hosts  would  find  the  EBCDIC  type  more  convenient.  The  sender 
converts  the  data  from  his  internal  character  representation  to  the  standard 
8-b1t  NVT-ASCII  representation  (see  the  TELNET  specification  in  MIL-STD  1782). 
Die  receiver  will  convert  the  data  from  the  standard  form  to  his  own  internal 
form.  In  accordance  with  the  NVT  standard,  the  <CRLF>  sequence  should  be 
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used,  where  necessary,  to  denote  the  end  of  a  line  of  text.  (See  the  discus¬ 
sion  of  file  structure  at  the  end  of  the  Section  on  Data  Representation  and 
Storage).  Using  the  standard  NVT-ASCII  representation  means  that  data  must  be 
interpreted  as  8-bit  bytes. 

5.2.2  EBCDIC  fonnat.  This  type  is  intended  for  efficient  transfer  between 
Hosts  which  use  EBCDIC  for  their  internal  character  representation.  For 
transmission  the  data  are  represented  as  8-bit  EBCDIC  characters.  The  char¬ 
acter  code  is  the  only  difference  between  the  functional  specifications  of 
EBCDIC  and  ASCII  types.  End-of-line  (as  opposed  to  end-of-record  —  see  the 
discussion  of  structure)  will  probably  be  rarely  used  with  EBCDIC  type  for 
purposes  of  denoting  structure,  but  where  it  is  necessary  the  <NL>  character 
should  be  used. 

5.3  Reasons  for  file  transfer.  A  character  file  may  be  transferred  to  a 
Host  for  one  of  three  purposes:  for  printing,  for  storage  and  later  retrieval, 
or  for  processing.  If  a  file  is  sent  for  printing,  the  receiving  Host  mnst 
know  how  the  vertical  format  control  is  represented.  In  the  second  case,  it 
must  be  possible  to  store  a  file  at  a  Host  and  then  retrieve  it  later  in 
exactly  the  same  fonn.  Finally,  it  ought  to  be  possible  to  move  a  file  from 
one  Host  to  another  and  process  the  file  at  the  second  Host  without  undue 
trouble. 

5.3,1  File  transfer  parameters.  A  single  ASCII  or  EBCDIC  format  does  not 
satisfy  all  these  conditions  and  so  these  types  have  a  second  parameter  speci¬ 
fying  one  of  the  following  three  formats: 

ho»~P<^int.  This  is  the  default  format  to  be  used  if  the  second 
(format)  parameter  is  omitted.  Non-print  format  must  be  accepted  by  all  FTP 
implementations.  The  file  need  contain  no  vertical  format  information.  If  it 
is  passed  to  a  printer  process,  this  process  may  assume  standard  values  for 
spacing  and  margins.  Normally,  this  format  will  be  used  with  files  destined 
for  processing  or  just  storage. 

5. 3. 1.2  TELNET  format  controls.  The  file  contains  ASCII/EBCDIC  vertical 
format  controls  (i.e.,  <CR>,  <LF^>,  <NL>,  <VT>,  <FF>)  which  the  printer  process 
will  interpret  appropriately.  <CRLF>,  in  exactly  this  sequence,  also  denotes 
end-of-line. 

5. 3. 1.3  *  ^he  file  v  ains  American  National  Standards 

Institute  (Akisi)  (FORTRAN )  vertical  fonr;  ntrol  characters.  In  a  line  or  a 

record,  formatted  according  to  tne  ASA  St».  rd,  the  first  character  is  not  to 

be  printed.  Instead  it  should  be  used  to  determine  the  vertical  movement  of 
the  paper  which  should  take  place  before  the  rest  of  the  record  is  printed. 

The  ANSI  Standard  specifies  the  following  control  characters: 
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Character  Vertical  Spacing 

blank  Move  paper  up  one  line 

0  Move  paper  up  two  lines 

1  Move  paper  to  top  of  next  page 

♦  No  movement,  I.e.,  overprint 

Clearly  there  must  be  some  way  for  a  printer  process  to  distinguish  the  end  of 
the  structural  entity.  If  a  file  has  record  structure  (see  below)  this  Is  no 
problem;  records  will  be  explicitly  marked  during  transfer  and  storage.  If 
the  file  has  no  record  structure,  the  <CRLF>  end-of-llne  sequence  Is  used  to 
separate  printing  lines,  but  these  format  effectors  are  overridden  by  the  ANSI 
controls. 


5.3.1 .4  Image.  The  data  are  sent  as  contiguous  bits  which,  for  transfer, 
are  packed  Into  the  8-b1t  transfer  bytes.  The  receiving  site  must  store  the 
data  as  contiguous  bits.  The  structure  of  the  storage  system  might  necessi¬ 
tate  the  padding  of  the  file  (or  of  each  record,  for  a  record-structured  file) 
to  some  convenient  boundary  (byte,  word  or  block).  This  padding,  which  must 
be  all  zeros,  may  occur  only  at  the  end  of  the  file  (or  at  the  end  of  each 
record)  and  there  must  be  a  way  of  Identifying  the  padding  bits  so  that  they 
may  be  stripped  off  if  the  file  Is  retrieved.  The  padding  transformation 
should  be  well  publicized  to  enable  a  user  to  process  a  file  at  the  storage 
site.  Image  type  Is  Intended  for  the  efficient  storage  and  retrieval  of 
files  and  for  the  transfer  of  binary  data.  It  Is  recommended  that  this  type 
be  accepted  by  all  FTP  Implementations. 

5.3.1. 5  Local  byte  size.  The  data  Is  transferred  in  logical  bytes  of  the 
size  specified  by  the  obligatory  second  parameter.  Byte  size.  The  value  of 
Byte  size  must  be  a  decimal  Integer;  there  is  no  default  value.  The  logical 
byte  size  is  not  necessarily  the  same  as  the  transfer  byte  size.  If  there  Is 
a  difference  In  byte  sizes,  then  the  logical  bytes  should  be  packed  contigu¬ 
ously,  disregarding  transfer  byte  boundaries  and  with  any  necessary  padding  at 
the  end.  Uhen  the  data  reaches  the  receiving  Host  It  will  be  transformed  in  a 
manner  dependent  on  the  logical  byte  size  and  the  particular  Host.  This 
transformation  must  be  Invertible  (that  Is  an  identical  file  can  be  retrieved 
If  the  same  parameters  are  used)  and  should  be  well  publicized  by  the  FTP 
Implementors. 

5.3.1. 5.1  Local  byte  exmyle  1.  A  user  sending  3$-b1t  floatlng^lnt 
numbers  to  a  Host  with  a  3Z-blt  word  could  send  his  data  as  Local  byte  with  a 
logical  byte  size  of  36.  The  receiving  Host  would  then  be  expected  to  store 
the  logical  bytes  so  that  they  could  be  easily  manipulated;  In  this  exmi^le 
putting  the  3C-b1t  logical  bytes  Into  64-b1t  double  words  should  suffice. 
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5. 3. 1.5. 2  Local  byte  example  2.  A  pair  of  hosts  with  a  36-b1t  word  size 
may  send  data  to  one  another  in  words  by  using  TYPE  L  36,  The  data  would  be 
sent  in  the  8~b1t  transmission  bytes  packed  so  that  9  transmission  bytes 
carried  two  host  words. 

5. 3. 1.6  File  parameter  caution.  A  file  must  be  stored  and  retrieved  with 
the  same  parameters  If  the  retrieved  version  Is  to  be  Identical  to  the  version 
originally  transmitted.  Conversely,  FTP  Implementations  must  return  a  file 
identical  to  the  original  If  the  parameters  used  to  store  and  retrieve  a  file 
are  the  same. 

5.3.2  File  structure.  In  addition  to  different  representation  types,  FTP 
allows  the  structure  o^  a  file  to  be  specified.  Three  file  structures  are 
defined  In  FTP: 

file-structure,  where  there  Is  no  Internal  structure  and  the  file 
Is  considered  to  be  a  continuous  sequence  of  data 
bytes, 

record-structure,  where  the  file  Is  made  up  of  sequential  records, 

and  page-structure,  where  the  file  Is  made  up  of  Independent  Indexed 
psqes. 

File-structure  Is  the  default,  to  be  assumed  If  the  STRUcture  command  has  not 
been  used  but  both  file  and  record  structures  must  be  accepted  for  "text* 
files  (i.e.,  files  with  TYPE  ASCII  or  EBCDIC)  by  all  FTP  Implementations.  The 
structure  of  a  file  will  affect  both  the  transfer  mode  of  a  file  (see  the 
Section  on  Transmission  Nodes)  and  the  Interpretation  and  storage  of  the 
file.  The  "natural*  structure  of  a  file  will  depend  on  which  Host  stores  the 
file.  A  source-code  file  will  usually  be  stored  In  fixed  length  records,  but 
may  also  be  stored  as  a  stream  of  characters  partitioned  Into  lines,  for 
exmnple  by  <CRIF>.  If  the  transfer  of  files  between  such  disparate  sites  Is 
to  be  useful,  there  must  be  some  way  for  one  site  to  recognize  the  other*s 
assumptions  about  the  file. 

5.3.2. 1  Flle^  vs.  r^or^rlented.  With  some  sites  being  naturally  file- 
oriented  and  others  naturally  record-oriented  there  may  be  problems  If  a  file 
with  one  structure  is  sent  to  a  Host  oriented  to  the  other.  If  a  text  file  Is 
sent  with  record-structure  to  a  Host  which  Is  file-oriented,  then  that  Host 
should  apply  an  internal  transformation  to  the  file  based  on  the  record  struc¬ 
ture.  Obviously  this  transformation  should  be  useful  but  It  must  also  be 
Invertible  so  that  an  Identical  file  may  be  retrieved  using  record  structure. 
In  the  case  of  a  file  being  sent  with  file-structure  to  a  record-oriented 
Host,  there  exists  the  question  of  what  criteria  the  Host  should  use  to  divide 
the  file  into  records  which  can  be  processed  locally.  If  this  division  Is 
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iMCMsarv  the  FTP  Imoleaientatlon  should  use  the  end-of-line 

ASCII  or  <NL>  for  HCDIC  text  files,  as  the  delimiter.  If  an  FTP  linple- 
aentatlon’ adopts  this  technique.  It  must  be  prepared  to  reverse  the  transfor¬ 
mation  If  the  file  1$  retrieved  with  file-structure. 

c  3  ?  2  Pane  structure.  To  transmit  files  that  are  discontinuous  FTP  ^  _ 
defies  a  paM  striKUiTT  Files  of  this  type  are  sometimes  known  as  random 
a2ce«  fliSs- or  e«n  as  "holey  files".  In  these  files  there  so***!** 
“her  InforiatVassoclated  with  the  file  as  a  whole  («-9-.«f 
tor^  or  with  «  section  of  the  file  {e.g.,  page  access  controls),  or  both,  in 
W/the  sections  of  the  file  are  called  pa^s.  To 

sixes  and  associated  information  each  page  is  sent  with  a  page  header.  The 
page  header  has  the  following  defined  fields: 

a  Header  Length.  The  number  of  logical  bytes  in  the  page  header 
including  this  byte.  The  minimuis  header  length  is  4. 


b. 


Pap.  Indtx.  Tht  loqlcal  pagt  numbor  of  WIs  tectl^on  of  ‘"e  nie. 
This  is  not  the  transmission  seguence  number  of  this  page,  but  the 
index  used  to  identify  this  page  of  the  file. 


Data  Length.  The  number  of  logical  bytes  in  the  page  data, 
minimum  oata  length  is  0. 


The 


d. 


Page  Type, 
defined: 


The  type  of  page  this  is.  The  following  page  types  are 


0  •  Last  Page 

This  is  used  to  indicate  the  end  of  a  paged  structured  trans- 
mission.  The  header  length  must  be  4,  and  the  data  length  must 
be  0. 


1  •  Simple  Page 

This  is  the  normal  type  for  simple  paged  files  with  no  page 
level  associated  control  information.  The  header  length  must 
be  4. 


2  -  Descriptor  Page 

This  type  is  used  to  transmit  the  descriptive  Information  for 
the  file  as  a  whole. 

3  *  Access  Controlled  Page 
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This  type  includes  an  additional  header  field  for  paged  files 
Mith  page  level  access  control  information.  The  header  length 
must  be  5. 

e.  Optional  Fields.  Further  header  fields  may  be  used  to  supply  per 
page  control  information,  for  example,  per  page  access  control. 

All  fields  are  one  logical  byte  in  length.  The  logical  byte  size  is  specified 
by  the  TYPE  command. 

5.4  Establishing  data  conn^t ions.  The  mechanics  of  transferring  data 
consists  of  setting  up  the  data  connection  to  the  appropriate  ports  and 
choosing  the  parameters  for  transfer.  Both  the  user  and  the  server-DTPs  have 
a  default  data  port.  The  default  data  connection  is  established  between  user 
process  port  U  and  server  port  L-1.  The  transfer  byte  size  is  B^it  bytes. 
This  byte  size  is  relevant  only  for  the  actual  transfer  of  the  data;  it  has  no 
bearing  on  representation  of  the  data  within  a  Host*s  file  system, 

5.4.1  Passive  data  transfer  process.  The  passive  data  transfer  process 
(this  may  be  a  user^DTP  or  a  second  server-DTP)  shall  "listen*  on  the  data 
port  prior  to  sending  a  transfer  request  command.  The  FTP  request  command 
determines  the  direction  of  the  data  transfer.  The  server,  upon  receiving  the 
transfer  request,  will  initiate  the  data  connection  to  the  port.  When  the 
connection  is  established,  the  data  transfer  begins  between  OTP's,  and  the 
server-PI  sends  a  confirming  reply  to  the  user-PI. 

5.4.2  Alternate  data,  it  is  possible  for  the  user  to  specify  an  alternate 
data  port  by  use  of  the  PORT  command.  For  example,  he  might  wwt  a  file 
retrieved  from  a  third  party  Host.  In  the  latter  case  the  user*PI  sets  up 
command  connections  with  both  server-PI's.  One  server  is  then  told  (by  an  FTP 
command)  to  •listen*  for  a  connection  which  the  other  will  initiate.  The 
user-PI  sends  one  server^-PI  a  PORT  command  indicating  the  data  port  of  the 
other.  Finally  both  are  sent  the  appropriate  transfer  commands.  The  exKt 
sequence  of  commands  and  replies  sent  between  the  user-controller  and  the 
servers  is  defined  in  the  Section  on  FTP  Replies.  In  general,  it  is  the 
server's  responsibility  to  maintain  the  data  connection  to  initiate  it  and  to 
close  it.  The  exception  to  this  is  when  the  user-OTP  is  sending  the  data  in  a 
transfer  mode  that  requires  the  connection  to  be  closed  to  indicate  EOF.  The 
server  MUST  close  the  data  connection  under  the  following  conditions: 

a.  The  server  has  completed  sending  data  in  a  transfer  mode  that 
requires  a  close  to  indicate  EOr. 


b.  The  server  receives  an  ABORT  command  from  the  user. 

c.  The  port  specification  is  changed  by  a  comMnd  from  the  user. 
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d.  The  TELNET  connection  is  closed  legally  or  otherwise. 

e.  An  Irrecoverable  error  condition  occurs* 

Otherwise  the  close  is  a  server  option,  the  exercise  of  which  he  must  Indicate 
to  the  user-process  by  an  appropriate  reply. 

5.5  Transwission  iy)de$.  The  next  consideration  in  transferring  data  is 
choosing  the  appropriate  transmission  mode.  There  are  three  modes:  one  which 
formats  the  data  and  allows  for  restart  procedures;  one  which  also  compresses 
the  data  for  efficient  transfer;  and  one  which  passes  the  data  with  little  or 
no  processing.  In  this  last  case  the  mode  interacts  with  the  structure  attri¬ 
bute  to  determine  the  type  of  processing.  In  the  compressed  mode  the  repre¬ 
sentation  type  determines  the  filler  byte.  All  data  transfers  must  be  com¬ 
pleted  with  an  end-of-file  (EOF)  which  may  be  explicitly  stated  or  implied  by 
the  closing  of  the  data  connection.  For  files  with  record  structure,  all  the 
enO-of-record  markers  (EOR)  are  explicit,  including  the  final  one.  For  files 
transmitted  in  page  structure  a  ”last«page*  page  type  is  used.  For  the  pur¬ 
pose  of  standardized  transfer,  the  sending  Host  will  translate  his  internal 
end  of  line  or  end  of  record  denotation  into  the  representation  prescribed  by 
the  transfer  mode  and  file  structure,  and  the  receiving  Host  will  perform  the 
inverse  translation  to  his  internal  ^notation.  A  host  specific  record  count 
field  may  not  be  recognized  at  another  Host,  so  the  end  of  record  Information 
may  be  transferred  as  a  two  byte  control  code  in  Stream  mode  or  as  a  flagged 
bit  in  a  Block  or  Compressed  mode  descriptor.  End  of  line  in  an  ASCII  or 
EBCDIC  file  with  no  record  structure  should  be  indicated  by  <CRLF>  or  <NL>, 
respectively.  Since  these  transformations  imply  extra  work  for  some  systems, 
identical  systems  transferring  non-record  structured  text  files  might  wish  to 
use  a  binary  representation  and  stream  mode  for  the  transfer. 

NOTE:  In  the  rest  of  this  section,  byte  means  "transfer  byte*  except  where 
explicitly  stated  otherwise. 

5.5.1  Transmission  modes  defined.  The  following  transmission  modes  are 
defined  in  lYP: 

^*^*^*^  Stray.  The  data  is  transmitted  as  a  stream  of  bytes.  There  is  no 
restriction  on  the  representation  type  used;  record  structures  are  allowed. 

In  a  record  structured  file  EON  and  EOF  will  each  be  indicated  by  a  two-hyte 
control  code.  The  first  byte  of  the  control  code  will  be  all  ones,  the  escape 
character.  The  second  b>te  will  Have  the  low  order  bit  on  and  zeros  elsetdiere 
for  EOR  and  the  second  low  order  bit  on  for  EOF;  that  is,  the  byte  will  have 
value  I  for  EOR  and  value  Z  for  EOF.  EOR  and  EOF  may  be  indicated  together  on 
the  last  b)te  transmitted  by  turning  both  low  order  bits  on,  i.e.»  the  value 
3.  If  a  byte  of  all  ones  was  intended  to  be  sent  as  data,  it  should  be 
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repeated  In  the  fecc^'d  byte  of  the  control  code.  If  the  structure  Is  flic 
structure,  the  EOF  Is  Indicated  by  the  sending  Host  closing  the  data  connec - 
ticn  and  all  byte-  are  data  bytes. 

5. 5. 1.2  Block.  The  file  Is  transmitted  as  a  series  of  data  blocks  preceded 
by  one  or  more  header  bytes.  The  header  bytes  contain  a  count  field,  and 
descriptor  code.  The  count  field  Indicates  the  total  length  of  the  data  block 
In  bytes,  thus  marking  the  beginning  of  the  next  data  block  (there  are  no 
filler  bits).  The  descriptor  code  defines:  last  block  In  the  file  (EOF)  last 
block  In  the  record  (EOR),  restart  marker  (see  the  Section  on  Error  Recovery 
and  Restart)  or  suspect  data  the  data  being  transferred  is  suspected  of 

errors  and  Is  not  reliable).  This  last  code  Is  NOT  Intended  for  error  control 
Ml thin  FTP.  It  Is  motivated  by  the  desire  of  sites  exchanging  certain  types 
of  data  (e.g.,  seismic  or  Meather  data)  to  send  and  receive  all  the  data 
despite  local  errors  Uuch  as  *magnet1c  tape  read  errors”),  but  to  Indicate  In 
the  transmission  that  cercain  portions  are  suspect).  Record  structures  are 
alloMed  In  this  mode,  and  any  representation  type  may  be  used.  The  header 
consists  of  the  three  bytes.  Of  the  24  bits  of  header  Information,  the  16  low 
order  bits  shall  represent  byte  count,  and  the  8  high  order  bits  shall  repre¬ 
sent  descriptor  codes  as  shown  In  Figure  4. 


nfacmfTQa 

•mcouirT 

•  WM 

lewM 

* 

FIGURE  4.  Block  header. 

S. 5. 1.2. I  Descriptor  codes.  The  descriptor  codes  are  Indicated  by  bit 
flags  In  the  descriptor  byte.  Four  codes  have  been  assigned,  where  each  code 
number  Is  the  decimal  value  of  the  corresponding  bit  In  the  byte. 

Code  Meaning 

128  End  of  data  block  Is  EOR 

64  End  of  data  block  Is  EOF 

32  Suspected  errors  In  data  block 
16  Data  block  Is  a  restart  marker 

With  this  encoding  more  than  one  descriptor  coded  condition  may  exist  for  a 
particular  block.  As  many  bits  as  necessary  may  be  flagged.  The  restart 
marker  Is  embedded  In  the  data  stream  as  an  Integral  number  of  8*b1t  bnes 
representing  printable  characters  In  the  language  being  used  over  the  TELNET 
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connection  (e.g.,  default—NVT-ASCII) .  <SP>  (Space,  in  the  appropriate  langu¬ 
age)  must  not  be  used  WITHIN  a  restart  marker.  For  example.  Figure  5  shows 
the  transmission  of  a  six-character  marker. 


dcscuftii 

CODE  »  1« 

- 1 - 

lYTE  COUNT 

-  6 

_ 1 _ 

MAKKER 

Sbitt 

MARKER 

SMtt 

MARKER 

8bH* 

MARKER 

MARKER 

MARKER 

•  Mtt 

•  Mtt 

•  Ml 

FIGURE  5.  Transmission  of  a  six-character  marker. 

5.5. 1.3  Compressed.  There  are  three  kinds  of  information  to  be  sent: 
regular  data,  sent  in  a  byte  string;  compressed  data,  consisting  of  replica¬ 
tions  or  filler;  and  control  information,  sent  in  a  two-byte  escape  sequence. 
If  n>0  bytes  (up  to  127)  of  regular  data  are  sent,  these  n  bytes  are  j? needed 
by  a  byte  with  the  left-most  bit  set  to  0  and  the  right-most  7  bits  containing 
the  number  n.  (See  Figure  6). 
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To  compress  a  string  of  n  replications  of  the  data  byte  d»  2  bytes  are  sent  as 
shown  in  Figure  7. 


FIGURE  7.  Replicated  bv 


A  string  of  n  filler  bytes  can  be  compressed  into  a  single  byte,  where  the 
filler  byte  varies  with  the  representation  type.  If  the  type  Is  ASCII  or 
EBCDIC  the  filler  byte  is  <SP>  (Space,  ASCII  code  32.,  EBCDIC  code  64).  If 
the  type  is  Image  or  Local  byte  the  filler  is  a  zero  byte.  (See  Figure  8). 


FIGURE  8.  Filler  strine 


The  escape  sequence  is  a  double  byte,  the  first  of  which  is  the  escape  byte 
(all  zeros)  and  the  second  of  which  contains  descriptor  codes  as  defined  in 
Block  mode.  The  descriptor  codes  have  the  same  meaning  as  in  Block  mode  and 
apply  to  the  succeeding  string  of  bytes.  Compressed  mode  is  useful  for 
obtaining  increased  bandwidth  on  very  large  network  transmissions  at  a  little 
extra  CPU  cost.  It  can  be  most  effectively  used  to  reduce  the  size  of  printer 
files  such  as  those  generated  by  RJE  Hosts. 


5.6  Error  recovery  and  restart.  There  is  no  provision  for  detecting  bits 
lost  or  scrambled  in  data  transfer;  this  level  of  error  control  is  handled  by 
the  TCP.  However,  a  restart  procedure  is  provided  to  protect  users  from  gross 
system  failures  (including  failures  of  a  Host,  an  FTP-process,  or  the  under¬ 
lying  network).  The  restart  procedure  is  defined  only  for  the  block  and 
compressed  modes  of  data  transfer.  It  requires  the  sender  of  data  to  insert  a 
special  marker  code  In  the  data  stream  with  some  marker  information.  The 
marker  information  has  meaning  only  to  the  sender,  but  must  consist  of 
printable  characters  in  the  default  or  negotiated  language  of  the  TELNET 
connection  (ASCII  or  EBCDIC).  The  marker  could  represent  a  bit-count,  a 
record-count,  or  any  other  information  by  which  a  system  may  identify  a  data 
checkpoint.  The  receiver  of  data,  if  it  implements  the  restart  procedure, 
would  then  mark  the  corresponding  position  of  this  marker  in  the  receiving 
system,  and  return  this  information  to  the  user.  In  the  event  of  a  system 
failure,  the  user  can  restart  the  data  transfer  by  identifying  the  marker 
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point  with  the  FTP  restart  procedure.  The  following  example  illustrates  the 
use  of  the  restart  procedure.  The  sender  of  the  data  Inserts  an  appropriate 
marker  block  in  the  data  stream  at  a  convenient  point.  The  receiving  Host 
marks  the  corresponding  data  point  in  its  file  system  and  conveys  the  last 
known  sender  and  receiver  marker  information  to  the  user,  either  directly  or 
over  the  command  connection  in  a  110  reply  (depending  on  who  is  the  sender). 

In  the  event  of  a  system  failure,  the  user  or  controller  process  restarts  the 
server  at  the  last  server  marker  by  sending  a  restart  command  with  server's 
marker  code  as  its  argument.  The  restart  command  is  transmitted  over  the 
command  connection  and  is  immediately  followed  by  the  command  (such  as  RETR, 
STOR  or  LIST)  which  was  being  executed  when  the  system  failure  occurred. 

5.7  File  transfer  functions.  The  coninuni cation  channel  from  the  user-PI  to 
the  server-PI  is  established  by  a  TCP  connection  from  the  user  to  a  standard 
server  port.  The  user  protocol  interpreter  is  responsible  for  sending  FTP 
commands  and  interpreting  the  replies  received;  the  server-PI  interprets 
coflinands,  sends  replies  and  directs  its  OTP  to  set  up  the  data  connection  and 
transfer  the  data.  If  the  second  party  to  the  data  transfer  (the  passive 
transfer  process)  is  the  user-OTP  then  it  is  governed  through  the  internal 
protocol  of  the  user-FTP  Host;  if  it  is  a  second  server-OTP  then  it  is 
governed  by  its  PI  on  conwand  from  the  user-PI.  The  FTP  replies  are  discussed 
in  the  next  section.  In  the  description  of  a  few  of  the  conmands  in  this 
section  it  is  helpful  to  be  explicit  about  the  possible  replies. 

5.7.1  FTP  commands.  The  following  are  FTP  commands: 

5. 7. 1.1  Access  control  cc^ands.  The  following  commands  specify  access 
control  identifiers  (command  codes  are  shown  in  parentheses). 

5.7*1,1.I  User  name  (USER).  The  argument  field  is  a  TELNET  string  identi¬ 
fying  the  user.  The  user  identification  is  that  which  is  required  by  the 
server  for  access  to  its  file  system.  This  command  will  normally  be  the  first 
command  transmitted  by  the  user  after  the  conwand  connections  are  made  (some 
servers  may  require  this).  Additional  identification  information  in  the  form 
of  a  password  and/or  an  account  command  may  also  be  required  by  some  servers. 
Servers  may  allow  a  new  USER  command  to  be  entered  at  any  point  in  order  to 
change  the  access  control  and/or  accounting  information.  This  has  the  effect 
of  flushing  any  user,  password,  and  account  Information  already  supplied  and 
beginning  the  login  sequence  again.  All  transfer  parameters  are  unchanged  and 
any  file  transfer  in  progress  is  completed  under  the  old  account. 

5. 7. 1.1.2  Password  (PASS).  The  argument  field  is  a  TELNET  string  identi¬ 
fying  the  user's  password.  This  command  must  be  innediately  preceded  by  the 
user  name  conwand,  and,  for  some  sites,  completes  the  user's  identification 
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for  access  control.  Since  password  information  is  quite  sensitive,  it  is 
desirable  in  general  to  "mask"  it  or  suppress  typeout.  It  appears  that  the 
server  has  no  foolproof  way  to  achieve  this.  It  is  therefore  the  responsi¬ 
bility  of  the  user-FTP  process  to  hide  the  sensitive  password  information. 

5. 7. 1.1. 3  Account  (ACCT).  The  argument  field  is  a  TELNET  string  identi¬ 
fying  the  user's  account.  The  command  is  not  necessarily  related  to  the  USER 
conmand,  as  some  sites  may  require  an  account  for  login  and  others  only  for 
specific  access,  such  as  storing  files.  In  the  latter  case  the  command  may 
arrive  at  any  time.  There  are  reply  codes  to  differentiate  these  cases  for 
the  automaton:  when  account  information  is  required  for  login,  the  response 
to  a  successful  PASSword  command  is  reply  code  332.  On  the  other  hand,  if 
account  information  is  NOT  required  for  login,  the  reply  to  a  successful 
PASSword  command  is  230;  and  if  the  account  information  is  needed  for  a 
command  issued  later  in  the  dialogue,  the  server  should  return  a  332  or  532 
reply  depending  on  whether  he  stores  (pending  receipt  of  the  ACCounT  command) 
or  discards  the  command,  respectively. 

5. 7. 1.1. 4  Reinitialize  (REIN).  This  command  terminates  a  USER,  flushing 
all  I/O  and  account  in^ormkion,  except  to  allow  any  transfer  in  progress  to 
be  completed.  All  parameters  are  reset  to  the  default  settings  and  the 
command  connection  is  left  open.  This  is  identical  to  the  state  in  which  a 
user  finds  himself  immediately  after  the  command  connection  is  opened.  A  USER 
command  may  be  expected  to  follow. 

5.7.1. 1.5  Logout  (QUIT).  This  command  terminates  a  USER  and  if  file  trans¬ 
fer  is  not  in  progress,  the  server  closes  the  command  connection.  If  file 
transfer  is  in  progress,  the  connection  will  remain  open  for  result  response 
and  the  server  will  then  close  it.  If  the  user-process  is  transferring  files 
for  several  USERs  but  does  not  wish  to  close  and  then  reopen  connections  for 
each,  then  the  REIN  command  should  be  used  instead  of  QUIT.  An  unexpected 
close  on  the  command  connection  will  cause  the  server  to  take  the  effective 
action  of  an  abort  (ABdR)  and  a  logout  (QUIT). 

5.7.2  Transfer  parameter  conwnands.  All  data  transfer  parameters  have 
default  values,  and  the  conmantrs  specifying  data  transfer  parameters  are 
required  only  if  the  default  parameter  values  are  to  be  changed.  The  default 
value  is  the  last  specified  value,  or  if  no  value  has  been  specified,  the 
standard  default  value  as  stated  here.  This  implies  that  the  server  must 
"remember"  the  applicable  default  values.  The  connands  may  be  in  any  order 
except  that  they  must  precede  the  FTP  service  request.  The  following  commands 
specify  data  transfer  parameters. 
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5. 7. 2.1  Data  port  (PORT).  The  argument  is  a  HOST-PORT  specification  for 
the  data  port  to  be  used  \r\  data  connection.  There  defaults  for  both  the  user 
and  server  data  ports,  and  under  normal  circumstances  this  command  and  its 
reply  are  not  needed.  If  this  command  ^s  used  the  argument  is  the  concatena¬ 
tion  of  a  32-bit  internet  host  address  and  a  16-bit  TCP  port  address.  This 
address  information  is  broken  into  8-bit  fields  and  the  value  of  each 

field  is  transmitted  as  a  decimal  number  (in  character  string  representa¬ 
tion).  The  fields  are  separated  by  commas.  A  port  command  would  be  PORT 
hl,h2,h3,h4,  pl,p2;  where,  hi  is  the  high  order  8  bits  of  the  internet  host 
address. 


5.7.2. 2  Passive  (PASV).  This  command  requests  the  server-OTP  to  "listen" 
on  a  data  port  (which  is  not  its  default  data  port)  and  to  wait  for  a  connec¬ 
tion  rather  than  initiate  one  upon  receipt  of  a  transfer  command.  The 
response  to  this  command  includes  the  host  and  port  address  this  server  is 
listening  on. 


5. 7. 2. 3  Representation  type  (TYPE).  The  argument  specifies  the  representa¬ 
tion  type  as  described  in  tne  section  on  Data  Representation  and  Storage. 
Several  types  take  a  second  parameter.  The  first  parameter  is  denoted  by  a 
single  TELNET  character,  as  is  the  second  Format  parameter  for  ASCII  and 
EBCDIC;  the  second  parameter  for  local  byte  is  a  decimal  integer  to  indicate 
Bytesize.  The  parameters  are  separated  by  a  <SP>  (Space,  ASCII  code  32.). 

The  following  codes  are  assigned  for  type: 


t  / 


A  -  ASCII 
E  -  EBCDIC 


N  -  Non-print 

T  -  TELNET  format  effectors 
C  -  Carriage  Control  (ASA) 


i  -  Image  ^  ^ 


L  <byte  size>  -  Local  byte  Byte  size 

The  default  representation  type  is  ASCII  Non-print.  If  the  Format  parameter 
is  changed,  and  later  just  the  first  argument  is  changed.  Format  then  returns 
to  the  Non-print  default. 

5. 7. 2. 4  File  structure  (STRU).  The  argument  is  a  single  TE’-NET  character 
code  specifying  file  structure  described  in  the  Section  on  Data  Representation 
and  Storage.  The  following  codes  are  assigned  for  structure: 


F  -  File  (no  record  structure) 
R  -  Record  structure 
P  -  Page  structure 

The  default  structure  is  File. 
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5. 7.2. 5  Transfer  mode  (MODE).  The  argument  Is  a  single  TELNET  character 
code  specifying  the  data  transfer  modes  described  in  the  Section  on  Transmis¬ 
sion  Modes.  The  following  codes  are  assigned  for  transfer  modes: 

S  -  Stream 
B  -  Block 
C  -  Compressed 

The  default  transfer  mode  is  Stream. 

5.7.3  FTP  service  commands.  The  FTP  service  commands  define  the  file 
transfer  or  the  i^^le  system  function  requested  by  the  user.  The  argument  of 
an  FTP  service  command  will  normally  be  a  pathname.  The  syntax  of  pathnames 
must  conform  to  server  site  conventions  (with  standard  defaults  applicable), 
and  the  language  conventions  of  the  command  connection.  The  suggested  default 
handling  is  to  use  the  last  specified  device,  directory  or  file  name,  or  the 
standard  default  defined  for  local  users.  The  commands  may  be  in  any  order 
except  that  a  "rename  from"  command  must  be  followed  by  a  "rename  to"  command 
and  the  restart  command  must  be  followed  by  the  interrupted  service  command. 
The  data,  when  transferred  in  response  to  FTP  service  commands,  shall  always 
be  sent  over  the  data  connection,  except  for  certain  informative  replies.  The 
following  commands  specify  FTP  service  requests: 

Retrieve  (RETR).  This  command  causes  the  server-DTP  to  transfer  a 
copy  of  the’TTTe,  specified  in  the  pathname,  to  the  serveror  user-OTP  at  the 
other  end  of  the  data  connection.  The  status  and  contents  of  the  file  at  the 
server  site  shall  be  unaffected. 

5.7.3. 2  Store  (STOP).  This  command  causes  the  server-DTP  to  accept  the 
data  transferred  via  tne  data  connection  and  to  store  the  data  as  a  file  at 
the  server  site.  If  the  file  specified  in  the  pathname  exists  at  the  server 
sHe  then  its  contents  shall  be  replaced  by  the  data  being  transferred.  A  new 
file  is  created  at  the  server  site  if  the  file  specified  in  the  pathname  does 
not  already  exist. 

5. 7. 3.3  Append  (with  create)  (APPE).  This  command  causes  the  server-DTP  to 
accept  the  data  transferred  via  the  <iata  connection  and  to  store  the  data  in  a 
file  at  the  server  site.  If  the  file  specified  in  the  pathname  exists  at  the 
server  site,  then  the  data  shall  be  appended  to  that  file;  otherwise  the  file 
specified  in  the  pathname  shall  be  created  at  the  server  site. 

5.7.3. 4  Ally ate  (ALLO).  This  command  may  be  required  by  some  servers  to 
reserve  suf/feient  storage  to  accommodate  the  new  file  to  be  transferred.  The 
argument  shall  be  a  decimal  integer  representing  the  number  of  bytes  (using 
the  logical  byte  size)  of  storage  to  be  reserved  for  the  file.  For  files  sent 
with  record  or  page  structure  a  maximum  record  or  page  size  (in  logical  bytes) 
might  also  be  necessary;  this  is  indicated  by  a  decimal  integer  in  a  second 
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argument  field  of  the  command.  This  second  argument  Is  optional,  but  when 
present  should  be  separated  from  the  first  by  the  three  TELNET  characters  <SP> 
R  <SP>.  This  command  shall  be  followed  by  a  STORe  or  APPEnd  command.  The 
ALLO  command  should  be  treated  as  a  NOOP  (no  operation)  by  those  servers  which 
do  not  require  that  the  maximum  size  of  the  file  be  declared  beforehand,  and 
those  servers  Interested  In  only  the  maximum  record  or  page  size  should  accept 
a  dummy  value  In  the  first  argument  and  Ignore  It. 

5. 7. 3. 5  Restart  (REST).  The  argument  field  represents  the  server  marker  at 
which  file  transfer  Is  to  be  restarted.  This  comnand  »^oes  not  cause  file 
transfer  but  "spaces*  over  the  file  to  the  specified  data  checkpoint.  This 
command  shall  be  limied lately  followed  by  the  appropriate  FTP  service  command 
which  shall  cause  file  transfer  to  resume. 

5. 7. 3. 6  Ryame  from  (RWFR).  This  command  specifies  the  file  which  Is  to  be 
renairied.  Tlrls  command  must  be  Inmedlately  followed  by  a  "rename  to"  command 
specifying  the  new  file  pathname. 

5.7.3. 7  Rename  to  (RNTO).  This  command  specifies  the  new  pathname  of  the 
file  specified  in  the  immediately  preceding  "rename  from"  command.  Together 
the  two  commands  cause  a  file  to  be  renamed. 

5.7. 3.8  Abort  (MOR).  This  command  tells  the  server  to  abort  the  previous 
FTP  servIceTonwand  and  any  associated  transfer  of  data.  The  abort  command 
may  require  "special  action",  as  discussed  In  the  Section  on  FTP  Commands,  to 
force  recognition  by  the  server.  ^  action  Is  to  be  taken  If  the  previous 
coamiand  has  been  completed  (Including  data  transfer).  The  TELNET  connection 
Is  not  to  be  closed  by  the  server,  but  the  data  connection  must  be  closed. 
There  are  two  cases  for  the  server  upon  receipt  of  this  command:  (1)  the  FTP 
service  command  was  already  completed,  or  (2)  the  FTP  service  command  Is  still 
In  progress. 


5. 7. 3.8.1  FTP  service  command  completed.  In  the  first  case,  the  server 
closes  the  data  connection  (if  it  is  open)  and  responds  with  a  226  reply. 
Indicating  that  the  abort  command  was  successfully  processed. 

5.7. 3.8.2  HP  service  command  In  progress.  In  the  second  case,  the  server 
aborts  the  FT?*  service  In  progress  and  closes  the  data  connection,  returning 
a  426  reply  to  Indicate  that  the  service  request  terminated  In  abnormally. 

The  server  then  sends  a  226  reply.  Indicating  that  the  abort  command  was 
successfully  processed. 

5. 7. 3, 9  Delete  (OELE).  This  command  causes  the  file  specified  In  the 
pathname  to  be  deleted  at  the  server  site.  If  an  extra  level  of  protection  Is 
desired  (such  as  the  query,  "DO  you  really  wish  to  deletew").  It  snould  be 
provided  by  the  user-FTP  process. 
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5.7.3.10  Change  working  directory  (CWO).  This  rommand  allows  the  user  to 
work  with  a  different  directory  or  dataset  for  file  storage  or  retrieval 
without  altering  his  login  or  accounting  information.  Transfer  parameters  are 
similarly  unchanged.  The  argument  is  a  pathname  specifying  a  directory  or 
other  system  dependent  file  group  designator. 

5.7.3.11  List  (LIST).  This  command  causes  a  list  to  be  sent  from  the 
server  to  the  passive  DTP.  If  the  pathname  specifies  a  directory,  the  server 
should  transfer  a  list  of  files  in  the  specified  directory.  If  the  pathname 
specifies  a  file  then  the  server  should  send  current  information  on  the  file. 

A  null  argument  implies  the  user's  current  working  or  default  directory.  The 
data  transfer  is  over  the  data  connection  in  type  ASCII  or  type  EBCDIC.  (The 
user  must  ensure  that  the  TYPE  is  appropriately  ASCII  or  EBCDIC). 

5.7.3.12  Name-list  (NLST).  This  command  causes  a  directory  listing  to  be 
sent  from  server  to  user  site.  The  pathname  should  specify  a  directory  or 
other  system-specific  file  group  descriptor;  a  null  argument  implies  the 
current  directory.  The  server  will  return  a  stream  of  names  of  files  and  no 
other  information.  The  data  will  be  transferred  in  ASCII  or  EBCDIC  type  over 
the  data  connection  as  valid  pathname  strings  separated  by  <CRLF>  or  <NL>. 
(Again  the  user  must  ensure  that  the  TYPE  is  correct.) 

5.7.3.13  Site  parameters  (SITE).  This  conwand  i*:  used  py  the  server  to 
provide  services  specific  to  nis  system  that  are  essential  to  file  transfer 
but  not  sufficiently  universal  to  be  included  as  commands  in  the  protocol. 

The  nature  of  these  services  and  the  specification  of  their  syntax  can  be 
stated  in  a  reply  to  the  HELP  SITE  command. 

5.7.3.14  Status  (STAT).  This  command  shall  cause  a  status  response  to  be 
sent  over  the  command  connection  in  the  form  of  a  reply.  The  command  may  be 
sent  during  a  file  transfer  (along  with  the  command  IP  and  Synch  s1gna1s*«*see 
the  Section  on  FTP  Commands)  in  which  case  the  server  will  respond  with  the 
status  of  the  operation  in  progress*  or  it  may  be  sent  between  file  trans¬ 
fers.  In  the  latter  case  the  command  may  have  an  argument  field.  If  the 
argument  is  a  pathname,  the  command  is  analogous  to  the  "list"  command  except 
that  data  shall  be  transferred  over  the  command  connection.  If  a  partial 
pathname  is  given*  the  server  may  respond  with  a  list  of  file  names  or  attri¬ 
butes  associated  with  that  specification.  If  no  argument  is  given*  the  server 
should  return  general  status  information  about  the  server  FTP  process.  This 
should  include  current  values  of  all  transfer  parameters  and  the  status  of 
connections. 


5.7.3.15  Help  (HELP).  This  command  shall  cause  the  server  to  send  helpful 
information  regarding  its  implementation  status  over  the  conmand  connection  to 
the  user.  The  command  may  take  an  argument  (e.g.*  any  command  name)  and 
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return  more  specific  information  as  a  response.  Tne  reply  is  type  211  or 
214.  It  is  suggested  that  HELP  be  allowed  before  entering  a  USER  command. 

The  server  may  use  this  reply  to  specify  site-dependent  parameters,  e.g.,  In 
response  to  HELP  SITE. 

S. 7.3. 16  Noop  (NOOP).  This  command  does  not  affect  any  parameters  or 
previously  entered  cdiwnands.  It  specifies  no  action  other  than  that  the  server 
send  an  OK  reply. 

5.7.4  TELNET  1 anquaqc.  The  File  Transfer  Protocol  follows  the  specifica¬ 
tions  of  the  TELNET  protocol  for  all  communications  over  the  command  connec¬ 
tion.  Since  the  language  used  for  TELNET  communication  may  be  a  negotiated 
option,  all  references  in  the  next  two  sections  will  be  to  the  "TELNET  langu¬ 
age"  and  the  corresponding  "TELNET  end  of  line  code".  Currently  one  may  take 
these  to  mean  NVT-ASCII  and  <CRLF>.  No  other  specifications  of  the  TELNET 
protocol  will  be  cited.  FTP  commands  are  "TELNET  strings"  terminated  by  the 
"TELNET  end  of  line  code".  The  command  codes  themselves  are  alphabetic  char¬ 
acters  terminated  by  the  character  <SP>  (Space)  if  parameters  follow  and 
TELNET-EOL  otherwise.  The  command  codes  and  the  semantics  of  conmands  are 
described  in  this  section;  the  detailed  syntax  of  commands  is  specified  in  the 
Section  on  Coanands,  the  reply  sequences  are  discussed  in  the  Section  on 
Sequencing  of  Commands  and  Replies,  and  scenarios  illustrating  the  use  of 
commands  are  provided  in  the  Section  on  Typical  FTP  Scenarios.  FTP  commands 
may  be  partitioned  as  those  specifying  access-control  identifiers,  data  trans¬ 
fer  parameters,  or  FTP  service  requests.  Certain  commands  (such  as  ABOR, 

STAT,  QUIT)  may  be  sent  over  the  command  connection  while  a  data  transfer  is 
in  progress.  Some  servers  may  not  be  able  to  monitor  the  conmand  and  data 
connections  simultaneously,  in  which  case  some  special  action  will  be  neces¬ 
sary  to  get  the  server*s  attention.  The  exact  form  of  the  "special  action"  is 
undefined;  but  the  following  ordered  format  is  tentatively  recommended: 

a.  User  system  Inserts  the  TELNET  "Interrupt  Process"  (IP)  signal  in 
the  TELNET  stream. 

b.  User  system  sends  the  TELNET  “Synch"  signal 

c.  User  system  inserts  the  cotmand  (e.g.,  ABOR)  in  the  TELNET  stream. 

d.  Server  PI,  after  receiving  "IP",  scans  the  TELNET  stream  for 
EXACTLY  ONE  FTP  command. 

(For  other  servers  this  may  not  be  necessary  but  the  actions  listed  above 
should  have  no  unusual  effect.) 

FTP  replies.  Replies  to  File  Transfer  Protocol  commands  are  devised  to 
ensure  rte  synclironi zat i on  of  requests  and  actions  in  the  process  of  file 
transfer,  and  to  guarantee  that  the  user  process  always  knows  the  state  of  the 
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Server,  Every  command  must  generate  at  least  one  reply,  although  there  may  be 
more  than  one;  in  the  latter  case,  the  multiple  replies  must  be  easily  dlstln- 
Ished.  In  addition,  some  commands  occur  In  sequential  groups,  such  as  USER, 


mediate  state  If  all  preceding  commands  have  been  successful.  A  failure  at 
any  point  In  the  sequence  necessitates  the  repetition  of  the  entire  sequence 
from  the  beginning.  The  details  of  the  command-reply  sequence  are  made 
explicit  In  a  set  of  state  diagrams  below.  An  FTP  reply  consists  of  a  three 
digit  number  (transmitted  as  three  alphanumeric  characters)  followed  by  some 
text.  The  number  Is  Intended  for  use  by  automata  to  determine  what  state  to 
enter  next;  the  text  Is  Intended  for  the  human  user.  It  Is  Intended  that  the 
three  digits  contain  enough  encoded  Information  that  the  user-process  (the 
User-PI)  will  not  need  to  examine  the  text  and  may  either  discard  It  or  pass 
It  on  to  the  user,  as  appropriate.  In  particular,  the  text  may  be  server- 
dependent,  so  there  are  likely  to  be  varying  texts  for  each  reply  code. 


5.8.1  FTP  reply  defined.  Formally,  a  reply  Is  defined  to  contain  the 
3-d1g1t  code,  folibweTbT'Space  <SP>,  followed  by  one  line  of  text  (where  some 
maximum  line  length  has  been  specified),  and  terminated  by  the  TELMET  end-of- 
llne  code.  There  will  be  cases,  however,  where  the  text  Is  lonwr  than  a 
single  line.  In  these  cases  the  complete  text  must  be  bracketed  so  the  User- 
process  knows  when  It  may  stop  reading  the  reply  (I.e.  stop  processing 
Input  on  the  command  connection)  and  go  do  other  things.  This  requires  a 
special  format  on  the  first  line  to  Indicate  that  more  than  one  lint  Is 
coming,  and  another  on  the  last  line  to  designate  It  as  the  last.  At  least 
one  of  these  must  contain  the  appropriate  reply  code  to  Indicate  the  state  of 
the  transaction.  To  satisfy  all  factions  It  was  decided  that  both  the  first 
and  last  line  codes  should  be  the  same.  Thus  the  format  for  multi-line 
replies  Is  that  the  first  line  will  begin  with  the  exact  required  reply  code, 
followed  Immediately  by  a  Hyphen,  (also  known  as  Minus),  followed  by 
text.  The  last  line  will  begin  with  the  same  code,  followed  Immediately  by  a 
Space  <SP>,  optionally  some  text,  and  the  TELNET  end-of-llne  code.  For 
example: 


121-First  line 
Second  line 

234  A  line  beginning  with  numbers 
123  The  last  line 

The  user-process  then  simply  needs  to  search  for  the  second  occurrence  of  the 
same  reply  code,  followed  by  <SP>  (Space),  at  the  beginning  of  a  line,  and 
Ignore  all  Intermediary  lines.  If  an  Intermediary  line  begins  with  a  3-d1g1t 
nuii6er.  the  Server  must  pad  the  front  to  avoid  confusion.  This  scheme  allows 
standard  system  routines  to  be  used  for  reply  Information  (such  as  for  the 
STAT  reply),  with  "artlflclar  first  and  last  lines  tacked  on.  In  the  rare 
cases  where  these  routines  are  able  to  generate  three  digits  and  a  Space  at 
the  beginning  of  any  line,  the  beginning  of  each  text  line  should  be  offset  by 
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%(Mt  neutral  text,  like  Space.  This  scheiie  assmaes  that  multi-line  replies 
may  not  be  nested.  We  have  found  that.  In  general,  nesting  of  replies  will 
not  occur,  except  for  random  system  messages  (also  called  spontaneous  replies) 
which  may  Interrupt  another  reply.  System  messages  (I.e.  those  not  processed 
by  the  FTP  server)  will  HOT  carry  reply  codes  and  may  occur  anywhere  In  the 
coanand-reply  sequence.  They  may  be  Ignored  by  the  User-process  as  they  are 
only  Information  for  the  human  user. 

5.8.2  Thre^lqlt  reply  defined.  The  three  digits  of  the  reply  each  have  a 
special  significance.  This  ts  Intended  to  allow  a  range  of  very  simple  to 
very  sophisticated  response  by  the  user-process.  The  first  digit  denotes 
whether  the  response  Is  good,  bad  or  Incomplete.  (Referring  to  the  state 
diagram)  an  unsophisticated  user-process  will  be  able  to  determine  Its  next 
action  (proceed  as  planned,  redo,  retrench,  etc.)  by  simply  examining  this 
first  digit.  A  user-process  that  wants  to  know  approximately  what  kind  of 
error  occurred  (e.g.  file  system  error,  command  syntax  error)  may  examine  the 
second  digit,  reserving  the  third  digit  for  the  finest  gradation  of  Informa¬ 
tion  (e.g.  RHTO  command  without  a  preceding  RNFR.) 

5. 8. 2.1  First  digit  values.  There  are  five  values  for  the  first  digit  of 
the  reply  co3iI 

5.8.2.1.1  Positive  preliminary  reply  (lya).  The  requested  action  Is  being 
Initiated;  expecC  another  reply  be/ore  pmeedlng  with  a  new  command.  (The 
user-process  sending  another  command  before  the  completion  reply  would  be  In 
violation  of  protocol;  but  server-fTP  processes  should  queue  any  commands  that 
arrive  while  a  preceding  command  Is  In  progress.)  This  type  of  reply  can  be 
used  to  Indicate  that  the  command  was  accepted  and  the  user-process  may  now 
pay  attention  to  the  data  connections,  for  Implementations  where  simultaneous 
monitoring  Is  difficult. 

5.8.2.1.2  Positive  completion  reply  (2y2).  The  requested  action  has  been 
successfully  completed. A  new  request  may  be  Initiated. 

5.8.2. 1.3  Positive  Intermediate  reply  (3yz).  The  command  has  been 
accepted,  but  the  requested  action  1$  being  held  In  abeyance,  pending  receipt 
of  further  Information.  The  user  should  send  another  command  specifying  this 
Information.  This  reply  Is  used  In  command  sequence  groups. 

5.8. 2. 1.4  Transient  negative  conyletlon  reply  (4y2).  The  command  was  not 
accepted  and  the  requested  action  did  not  take  place,  but  the  error  condition 
Is  temporary  and  the  action  may  be  requested  again.  The  user  should  return  to 
the  beginning  of  the  comMnd  sequence.  If  any.  It  Is  difficult  to  assign  a 
meaning  to  "translenf,  particularly  when  two  distinct  sites  (Server  and 
User-processes)  have  to  agree  on  the  Interpretation.  Each  reply  In  the  4yz 
category  might  have  a  slightly  different  time  value,  but  the  Intent  Is  that 
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the  user-process  Is  encouraged  to  try  again.  A  rule  of  thun^  in  deteniining 
if  a  reply  fits  into  the  4yz  or  the  Byz  (Permanent  Negative)  category  is  that 
replies  are  4yz  if  the  commands  can  be  repeated  without  any  change  in  coaMnd 
form  or  in  properties  of  the  User  or  Server  (e.g.  the  command  is  spelled  the 
same  with  the  same  arguments  used;  the  user  does  not  change  his  file  access  or 


user  name;  the  server  does  not  put  up  a  new  implementation.) 

5.8.2. 1.5  Permanent  negative  completion  reply  (5yz).  The  command  was  not 
accepted  and  the  repuesteo  action  did  not  take  place.  The  User-process  is 
discouraged  from  repeating  the  exact  request  (in  the  same  sequence).  Even 
some  ‘‘permanent'*  error  conditions  can  be  corrected,  so  the  human  user  may  want 
to  direct  his  User-process  to  reinitiate  the  command  sequence  by  direct  action 
at  some  point  in  the  future  (e.g.  after  the  spelling  has  been  changed,  or  the 
user  has  altered  his  directory  status.) 

5. 8.2. 2  Second  digit  values.  The  following  function  groupings  are  encoded 
in  the  second  digit: 

5.8.2. 2.1  Syntax  (xOz).  These  replies  refer  to  syntax  errors,  syntacti¬ 
cally  correct  commands  tfiat  don't  fit  any  functional  category,  unimplemented 
or  superfluous  commands. 

5.8.2. 2.2  Information  (xlz).  These  are  replies  to  requests  for  informa¬ 
tion,  such  as  status  or  help. 

5.8.2. 2. 3  Connections  (x2z).  Replies  referring  to  the  command  and  data 
connections. 


5.8. 2. 2, 4.  Authentication  and  accounting 
process  and  accounting  procedures. 


Replies  for  the  login 


5.8.2. 2.5 


tcified 


5.8,2. 2.6  File  system  (x5z).  These  replies  Indicate  the  status  of  the 
Server  file  system  vis-a-vTs  the  requested  transfer  or  other  file  system 
action. 

5.8.2. 3  Third  digit  values.  The  third  digit  gives  a  finer  gradation  of 
meaning  in  each  of  Ene  function  categories,  specified  by  the  second  digit. 

The  list  of  replies  below  will  illustrate  this.  Note  that  the  text  associated 
with  each  reply  is  recommended,  rather  than  mandatory,  and  may  even  change 
according  to  the  command  with  which  it  is  associated.  The  reply  codes,  on  the 
other  hand,  must  strictly  follow  the  specifications  in  the  last  section;  that 
is.  Server  implementations  should  not  invent  new  codes  for  situations  that  are 
only  slightly  different  from  the  ones  described  here,  but  rather  should  adapt 
codes  already  defined.  A  comniapcl  such  as  TYPE  or  ALLO  whose  successful  execu¬ 
tion  does  not  offer  the  user-orocess  any  new  information  will  cause  a  200 
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reply  to  be  returned.  If  the  command  Is  not  Implemented  by  a  particular 
Server-FTP  process  because  It  has  no  relevance  to  that  computer  system,  for 
example  AUO  at  a  T0PS20  site,  a  Positive  Completion  reply  Is  still  desired  so 
that  the  simple  User-process  knows  It  can  proceed  with  Its  course  of  action. 

A  202  reply  Is  used  In  this  case  with,  for  example,  the  reply  text:  "No 
storage  allocation  necessary."  If,  on  the  other  hand,  the  command  requests  a 
non-site-specific  action  and  Is  un Imp lamented,  the  response  Is  502.  A  refine¬ 
ment  of  that  Is  the  504  reply  for  a  command  that  IS  Implemented,  but  that 
requests  an  unimplemented  parameter. 

5.8.3  Reply  codes  by  function  groups. 

a.  200  Command  okay. 

b.  500  Syntax  error,  command  unrecognized. 

[This  may  Include  errors  such  as  command  line  too  long.] 

c.  501  Syntax  error  In  parameters  or  arguments. 

d.  202  CoMiand  not  Implemented,  superfluous  at  this  site. 

e.  502  Command  not  Implemented. 

f.  503  Bad  sequence  of  commands. 

g.  504  Command  not  Implemented  for  that  par  Meter. 

h.  110  Restart  marker  reply. 

In  this  case  the  text  Is  exact  and  not  left  to  the  particular 
Implementatlo.i;  It  must  read: 

NARK  yyyy  «  mnnia 

where  yyyy  Is  User-process  data  streM  marker,  and  mmmm  server’s 
equivalent  marker.  (Note  the  spaces  between  markers  and  "•".) 

I.  119  Terminal  not  available,  will  try  mailbox. 

J.  211  System  status,  or  system  help  reply. 

k.  212  Directory  status. 

l.  213  File  status. 

m.  21<  Help  message. 

(On  how  to  use  the  server  or  the  meaning  of  a  particular  nonstan¬ 
dard  command.  This  reply  is  useful  only  to  the  human  user.) 
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n.  215  <scheiiie>  Is  the  preferred  scheme. 

0.  120  Service  ready  in  nnn  minutes. 

p.  220  Service  ready  for  new  user. 

q.  221  Service  closing  TELMET  connection. 

(logged  out  if  appropriate) 

r.  421  Service  not  available,  closing  TELMET  connection. 

[This  may  be  a  reply  to  any  command  if  the  service  knows  it  must 
shut  down.] 

s.  125  Data  connection  already  open;  transfer  starting. 

t.  225  Oata  connection  open;  no  transfer  in  progress. 

u.  425  Can't  open  data  connection. 

V.  226  Closing  data  connection:  requested  file  action  successful. 
(For  example,  file  transfer  or  file  abort.) 

w.  426  Connection  closed;  transfer  aborted. 

X.  227  Entering  Passive  Mode.  hl,h2,h3,h4,pl,p2. 

y.  230  User  logged  in,  proceed. 

z.  530  Not  logged  in. 

aa.  331  User  name  okay,  need  password. 

bb.  332  Need  account  for  login. 

cc.  532  Need  account  for  storing  files. 

dd.  150  File  status  okay;  about  to  open  data  connection. 

ee.  151  User  not  local;  Will  forward  to  <uscr>P<host>. 

ff.  152  User  Unknown;  Mail  will  be  rorwarded  by  the  operator. 

gg.  250  Requested  file  action  okay,  cos^letad. 

hh.  350  Requested  file  action  pending  further  information. 
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ii.  450  Requested  file  action  not  taken:  file  unavailable  (e.g, 
file  busy). 

jj.  550  Requested  action  not  taken:  file  unavailable  (e.g.  file  not 
found,  no  access). 

kk.  451  Requested  action  aborted:  local  error  in  processing. 

11.  551  Requested  action  aborted:  page  type  unknown. 

mm.  452  Requested  action  not  taken:  insufficient  storage  space  in 
system 

nn.  552  Requested  file  action  aborted:  exceeded  storage  allocation, 
(for  current  directory  or  dataset) 

00.  553  Requested  action  not  taken:  file  name  not  allowed 

pp.  354  Start  mail  input;  end  with  <CRxLF>.<CRxLF>. 

5.8.4  Numeric  order  list  of  re^ly  codes. 

a.  110  Restart  marker  reply. 

In  this  case  the  text  is  exact  and  not  left  to  the  particular 
Implementation;  It  must  read: 

MARK  yyyy  «  mmmm 

where  yyyy  is  User-process  data  stream  marker,  and  mnmm  server's 
equivalent  marker,  {note  the  spaces  between  markers  and  “«“.) 

b.  119  Terminal  not  available,  will  try  mailbox. 

c.  120  Service  ready  in  nnn  minutes. 

d.  125  Data  connection  already  open;  transfer  starting. 

e.  150  File  status  okay;  about  to  open  data  connection. 

f.  151  User  not  local;  Will  forward  to  <user>9<host>. 

g.  152  User  Unknown;  Mail  will  be  forwarded  by  the  operator. 

h.  200  Command  okay. 

I.  202  Command  not  Implemented,  superfluous  at  this  site. 

J.  211  System  status,  or  system  help  reply. 


'a\v 
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k.  212  Directory  status. 

l.  213  File  status. 

m.  214  Help  message. 

(On  how  to  use  the  server  or  the  meaning  of  a  particular  nonstan¬ 
dard  command.  This  reply  is  useful  only  to  the  human  user.) 

n.  215  <scheme>  is  the  preferred  scheme. 

0.  220  Service  ready  for  new  user. 

p.  221  Service  closing  TELNET  connection. 

{Logged  out  if  appropriate.) 

q.  225  Data  connection  open;  no  transfer  In  progress. 

r.  226  Closing  data  connection;  requested  file  action  successful. 
(For  example,  file  transfer  or  file  abort.) 

s.  227  Entering  Passive  Mode.  hl,h2,h3,h4,pl,p2 

t.  230  User  logged  In,  proceed. 

u.  250  Requested  file  action  okay,  completed. 

V.  331  User  name  okay,  need  password. 

w.  332  Need  account  for  login. 

X.  350  Requested  file  action  pending  further  Infonaatlon. 

y.  354  Start  mall  Input;  end  with  <CRxLF>.<CRxLF>. 

z.  421  Service  not  available,  closing  TELNET  connection. 

[This  may  be  a  reply  to  any  command  If  the  service  knows  It 
must  shut  down.] 

aa.  425  Can't  open  data  connection. 

bb.  426  Connection  closed;  transfer  aborted. 

cc.  450  Requested  file  action  not  taken:  file  unavailable  (e.g. 
file  busy). 

dd.  451  Requested  action  aborted:  local  error  In  processing. 
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ee.  452  Requested  action  not  taken:  Insufficient  storage  space  In 
system. 

ff.  500  Syntax  error,  conmand  unrecognized. 

[This  may  Include  errors  such  as  command  line  too  long.] 

gg.  501  Syntax  error  In  parameters  or  arguments. 

hh.  502  Command  not  Implemented. 

11.  503  Bad  sequence  of  coiriiiands. 

jj.  504  Command  not  Implemented  for  that  parameter. 

kk.  530  Not  logged  In. 

11.  532  Need  account  for  storing  files. 

mm.  550  Requested  action  not  taken:  file  unavailable  (e.g.  file  not 
found,  no  access). 

nn.  551  Requested  action  aborted:  page  type  unknown. 

00.  552  Requested  file  action  aborted:  exceeded  storage  allocation 
(for  current  directory  or  dataset). 

pp.  553  Requested  action  not  taken:  file  name  not  allowed. 

5.9  Declarative  specifications. 

5.9.1  Mirlmum  iiBDlefiientatlon.  In  order  to  make  FTP  workable  without  need¬ 
less  error  r/iessages,  the  following  minimum  Implementation  Is  required  for  all 
servers: 

TYPE  -  ASCII  Non-print 
MODE  -  Stream 
STRUCTURE  -  FYtle,  Record 
COHNANOS  -  USER,  QUIT,  PORT, 

TYPE,  MODE.  STRU, 
for  the  default  values 
RETR,  STOR. 

NOOP. 
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The  default  values  for  transfer  parameters  are: 

TYPE  -  ASCII  Non-print 
MODE  -  Stream 
STRU  -  File 

All  Hosts  must  accept  the  above  as  the  standard  defaults. 

5.9.2  Connections.  The  server  protocol  interpreter  shall  "listen"  on  Port 
L.  The  user  or  user  protocol  interpreter  shall  initiate  the  full-duplex 
command  connection.  Serverand  userprocesses  should  follow  the  conventions  of 
the  TELNET  protocol  as  specified  in  MIL-STD  1782,  TELNET  Protocol.  Servers 
are  under  no  obligation  to  provide  for  editing  of  command  lines  and  may 
specify  that  it  be  done  in  the  user  Host.  The  command  connection  shall  be 
closed  by  the  server  at  the  user's  request  after  all  transfers  and  replies  are 
completed.  The  user-DTP  must  "listen"  on  the  specified  data  port;  this  may  be 
the  default  user  port  (U)  or  a  port  specified  in  the  PORT  command.  The  server 
shall  initiate  the  data  connection  from  his  own  default  data  port  (L-1)  using 
the  specified  user  data  port.  The  direction  of  the  transfer  and  the  port 
used  will  be  determined  by  the  FTP  service  command. 

5. 9. 2.1  Command-reply  sequence.  When  data  Is  to  be  transferred  between  two 
servers,  A  aWB  (refer  to  figure  2),  the  user-PI,  C,  sets  up  command  connec¬ 
tions  with  both  server-PI's.  One  of  the  servers,  say  A,  is  then  sent  a  PASV 
command  telling  him  to  "listen"  on  his  data  port  rather  than  Initiate  a  con¬ 
nection  when  he  receives  a  transfer  service  command.  When  the  user^PI 
receives  an  acknowledgment  to  the  PASV  command,  which  Includes  the  identity  of 
the  host  and  port  being  listened  on,  the  usei^PI  then  sends  A's  port,  a,  to  B 
In  a  PORT  command;  a  reply  is  returned.  The  user-PI  may  then  send  the  corre¬ 
sponding  service  commands  to  A  and  B.  Server  B  Initiates  the  connection  and 
the  transfer  proceeds.  The  command-reply  sequence  Is  listed  below  where  the 
messages  are  vertically  synchronous  but  horizontally  asynchronous: 

User-PI  -  Server  A  User-PI  -  Server  B 


C->A  :  Connect  C->B  :  Connect 

C->A  :  PASV 

A->C  :  227  Entering  Passive  Node.  Al,A2,A3,A4,al,a2 

C->8  :  PORT  Al,A2,A3,A4.al,a2 

B->C  :  200  (may 

C->  ;  STOR  C->B  :  RETR 

B->A  :  Connect  to  HOST-A,  PORT-a 

The  data  connection  shall  he  closed  by  the  server  under  the  conditions 
described  in  the  Section  on  Establishing  Data  Connections.  If  the  server 
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wishes  to  close  the  connection  after  a  transfer  where  It  Is  not  required,  he 
should  do  so  Innedlately  after  the  file  transfer  Is  completed.  He  should  not 
wait  until  after  a  new  transfer  command  Is  received  because  the  user-process 
will  have  already  tested  the  data  connection  to  see  If  It  needs  to  do  a 
"listen";  (recall  that  the  user  must  "listen"  on  a  closed  data  port  BEFORE 
sending  the  transfer  request).  To  prevent  a  race  condition  here,  the  server 
sends  a  reply  (226)  after  closing  the  data  connection  (or  If  the  connection  Is 
left  open,  a  "file  transfer  completed"  reply  (250)  and  the  user-PI  should  wait 
for  one  of  these  replies  before  Issuing  a  new  transfer  command. 

5.9.3  Commands.  The  commands  are  TELNET  character  string  transmitted  over 
the  command  connections  as  described  In  the  Section  on  FTP  Commands.  The 
command  functions  and  semantics  are  described  In  the  Section  on  Access  Control 
Commands,  Transfer  Parameter  Conwands,  FTP  Service  Commands,  and  Miscellan¬ 
eous  Commands.  The  command  syntax  Is  specified  here.  The  commands  begin  with 
a  command  code  followed  by  an  argument  field.  The  command  codes  are  four  or 
fewer  alphabetic  characters.  Upper  and  lower  case  alphabetic  characters  are 
to  be  treated  Identically.  Thus,  RETR,  Retr,  retr,  ReTr,  or  rETr  may 
represent  the  retrieve  command.  This  also  applies  to  any  symbols  representing 
parameter  values,  such  as  A  or  a  for  ASCII  TYPE.  The  command  codes  and  the 
argument  fields  are  separated  by  one  or  more  spaces.  The  argument  field 
consists  of  a  variable  length  character  string  ending  with  the  character 
sequence  <CRLF>  (Carriage  Return,  Linefeed)  for  NYT-ASCII  represen-  tatlon; 
for  other  negotiated  languages  a  different  end  of  line  character  might  be 
used.  It  should  be  noted  that  the  server  1$  to  take  NO  action  until  the  end 
of  line  code  1$  received.  The  syntax  Is  specified  below  In  NVT-ASCII.  All 
characters  In  the  argument  field  are  ASCII  characters  Including  any  ASCII 
represented  decimal  Integers.  Square  brackets  denote  an  optional  argument 
field.  If  the  option  Is  net  taken,  the  appropriate  default  Is  Implied. 

5.9. 3.1  FTP  command  list.  The  following  are  the  FTP  commands: 

USER  <SP>  <username>  <CRLF> 

PASS  <SP>  <password>  <CRLF> 

ACCT  <SP>  <account  1nformat1on>  <CRLF> 

REIN  <CRLF> 

QUIT  <CRLF> 

PORT  <SP>  <Host-port>  <CRLF> 

PASV  <CRLF> 

TYPE  <SP>  <type  code>  <CRLF> 

STRU  <$P>  <structure  code>  <CRLF> 

MODE  <SP>  <tiode  code>  <CRLF> 

RETR  <SP>  <pathnaiie>  <CRLF> 

STOR  <SP>  <pathnaiie>  <CRLF> 

APPE  <SP>  <pathnafiie>  <GRLF> 

ALLO  <SP>  <dec1ma1  1nte9er> 

[<SP>  R  <SP>  <dec1mal  1nte9er>]  <CRLF> 
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REST  <SP>  <marker>  <CRLF> 

RNFR  <SP>  <pathname>  <CRLF> 

RNTO  <SP>  <pathname>  <CRLF> 

ABOR  <CRLF> 

DELE  <SP>  <pathname>  <CRLF> 

CWD  <SP>  <pathname>  <CRLF> 

LIST  [<SP>  <pathname>]  <CRLF> 

NLST  [<SP>  <pathname>]  <CRLF> 

SITE  <SP>  <string>  <CRLF> 

STAT  [<SP>  <pathnanie>]  <CRLF> 

HELP  [<SP>  <string>]  <CRLF> 

NOOP  <CRLF> 

5. 9. 3. 2  FTP  command  syntax.  The  syntax  of  the  above  argument  fields  (using 
BNF  notation  where  applicable  )  Is: 

<username>  <string> 

<password>  <str1ng> 

<account  1nformat1on>  <str1ng> 

<str1ng>  : <char>  <char><str1ng> 

<char>*  any  of  the  128  ASCII  characters  except  <CR>  and  <LF> 
<marker>  <pr  str1ng> 

<pr  str1ng>  <pr  char>  <pr  charxpr  str1ng> 

<pr  char>  : printable  characters,  any 
ASCII  code  33  through  126 
<byte  s1ze>  any  decimal  Integer  1  through  255 

<Host-port>  <Host-number>,<Port-number> 

<Host-number>  <number>,<number>,<number>,<number> 

<Port*number>  < n umber >,<n umber > 

<number>  any  decimal  Integer  0  through  255 
<ident>  <str1ng> 

<scheme>  : R  T  ? 

<form  code>  : N  T  C 

<type  code>  : :«  A  [<SP>  <form  code>] 

E  [<SP>  <form  code>] 

I 

L  <SP>  <byte  size> 

<structurc  code>  : F  R  P 
<modc  code>  : S  B  C 
<pathname>  :  :•  <str1ng> 

5.10  Sequencing  of  coffinands  and  replies.  The  comnunlcatioft  between  the 
user  and  server  is  intended  to  be  an  alternating  dialogue.  As  such,  the  user 
Issues  an  FTP  command  and  the  server  responds  with  a  prompt  primary  reply. 
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The  user  should  wait  for  this  initial  primary  success  or  failure  response 
before  sending  further  commands.  Certain  commands  require  a  second  reply  for 
which  the  user  should  dlso  wait.  These  replies  may,  for  example,  report  on 
the  progress  or  completion  of  file  transfer  or  the  closing  of  the  data  connec¬ 
tion.  They  are  secondary  replies  to  file  transfer  commands.  One  important 
group  of  informational  replies  is  the  connection  greetings.  Under  normal 
circumstances,  a  server  will  send  a  220  reply,  "awaiting  input",  when  the 
connection  is  completed.  The  user  should  wait  for  this  greeting  message 
before  sending  any  commands.  If  the  server  is  unable  to  accept  input  right 
away,  he  should  send  a  120  "expected  delay"  reply  imsediately  and  a  220  reply 
when  ready.  The  user  will  then  know  not  to  hang  up  if  there  is  a  delay.  The 
table  below  lists  alternative  success  and  failure  replies  for  each  command. 
These  must  be  strictly  adhered  to;  a  server  may  substitute  text  in  the 
replies,  but  the  meaning  and  action  implied  by  the  code  numbers  and  by  the 
specific  command  reply  sequence  cannot  be  altered. 

5.10.1  Command-reply  sequences.  In  this  section,  the  command-reply 
sequence  is  presented.  Each  command  is  listed  with  its  possible  replies; 
command  groups  are  listed  together.  Preliminary  replies  are  listed  first 
(with  their  succeeding  replies  indented  and  under  them),  then  positive  and 
negative  completion,  and  finally  intermediary  replies  with  the  remaining 
commands  from  the  sequence  following.  This  listing  forms  the  basis  for  the 
state  diagrams,  which  will  be  presented  separately. 

Connection  Establishment 
120 

220 

220 

421 

Login 

USER 

2X 

530 

500,  501,  421 
331.  332 
PASS 
230 
202 
5X 

500  ,  501.  503  .  421 
332 
ACCT 
230 
202 
530 

500,  501,  503..  421 
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LIST.  NLST 
125.  150 
226.  250 
425.  426.  451 
450 

500.  501.  502.  421.  530 

APPE 

125.  150 
(110) 

226.  250 

425.  426.  451.  551.  552 
532.  450.  550.  452.  553 
500.  501.  502.  421.  530 

RNFR 

450.  550 

500.  501.  502.  421.  530 
350 

RNTO 

250 

532.  553 

500.  501.  502.  503.  421.  530 
DELE.  CWD 
250 

450.  550 

500.  501.  502.  421*  530 

ABOR 

225.  226 

500.  501.  502.  421 
InfonMtlontl  comands 
STAT 

211.  212.  213 
450 

500.  501.  502.  421.  530 
HELP 

211.  214 

500.  501.  502.  421 

NlscelUn  <  romnds 

SITE 

200 

202 

500.  501.  530 
NOOP 
200 

SOC  421 
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5.11  State  diagrams.  Here  are  presented  state  diagrams  for  a  very  simple 
FTP  implementation.  Only  the  first  digit  of  the  reply  codes  Is  used.  There  is 
one  state  diagram  for  each  group  of  FTP  commands  or  command  sequences.  The 
command  groupings  were  determined  by  constructing  a  model  for  each  command 
then  collecting  together  the  commands  with  structurally  Identical  models.  For 
each  command  or  command  sequence  there  are  three  possible  outcomes:  success 
($)•  failure  (F),  and  error  (E).  In  the  state  diagrams  below  we  use  the  symbol 
B  for  "begin",  and  the  symbol  U  for  "wait  for  reply". 

Figure  9  represents  the  largest  group  of  FTP  commands. 

5.11.1  Largest  group  of  FTP  commands. 


FIGURE  9.  Largest  group  of  FTP  commands. 

Figure  9  models  the  commands  ABORt  ALLO,  DELE,  CUD,  HELP,  NDDE,  MRCP.  MRCP, 
MPSQ,  NOOP,  PASV,  QUIT,  SITE,  PORT,  STAT,  STRU  and  TYPE. 

5.11.2  Other  large  group  of  FTP  coi^ands.  The  other  large  group  of 
commands  is  repr^sentea  by  a  very  similar  diagram. 


i 


MILITARY  STANDARDS:  FTP 


MIL-STD  1780 


MIL.STD-1780 
10  May  1984 


Figure  10  Models  the  comiands  APPE.  LIST.  NLFL,  NLST,  REIN.  RETR.  STOR.  Note 
that  this  second  Model  could  also  be  used  to  represent  the  first  group  of 
coMMands*  the  only  difference  being  that  In  the  first  group  the  100  series 
replies  are  unexpected  and  therefore  treated  as  error,  while  the  second  group 
expects  (soMe  May  require)  100  series  replies. 


5.1L3  RenajM*  sequence  cowaand.  The  remaining  diagrams  model  command 
sequences*  perhaps  the  sWlest  of  these  Is  the  rename  sequence  shown  In 
Figure  11. 
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5.1L6  Cofflmand  and  reply  Interchange*  Finally,  Is  presented  a  generalized 
diagram  that  could  be  used  to  model  tne  cowiiand  and  reply  Interchange: 
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6.  TYPICAL  FTP  SCENARIO 

6.1  Scenario.  User  at  Host  U  wanting  to  transfer  files  to/from  Host  S. 

In  general  the  user  will  communicate  to  the  server  via  a  mediating  user-FTP 
process.  The  following  may  be  a  typical  scenario.  The  user-FTP  prompts  are 

shown  In  parentheses,  ' - >*  represents  commands  from  Host  U  to  Host  S,  and 

'< - 'represents  replies  from  Host  S  to  Host  U. 

LOCAL  COMMANDS  BY  USER  ACTION  INVOLVED 


ftp  (host)  opsys<CR> 


username  Doe  <CR> 


password  pswd  <CR> 

retrieve  (local  type)  ASCII<CR> 
(local  pathname)  test  I  <CR> 
(for. pathname)  test.pll<CR> 


<CRLF> 


type  Image<CR> 

< — 

store  (local  type)  1mage<CR> 
local  pathname)  file  dump<01> 
for. pathname)  >udd>cn>fd<CR> 

terminate 


Connect  to  Host  S,  port  L, 
establishing  command  connections 

<  -  220  Service  ready  <CRLF> 

USER  Ooe<CRLF> - > 

<  - 331  User  name  ok, 

need  password<CRLF> 

PASS  mun^le<CRLF>-^ — 

<  -  230  User  logged  1n.<CRLF> 

User-FTP  opens  local  file  In  ASCII. 
RETR  test.pll<CRLF>  - > 

<  -  150  File  status  okay; 

about  to  open  data  connection 
Server  makes  data  connection 
to  port  U 

<  -  226  Closing  data  connection, 

file  transfer  successful<CRLF> 

TYPE  I<CRLF> 

•  200  Command  0K<CRLF> 

User-FTP  opens  local  file  In  Image. 
STOR  >udd>cn>fd<CRLF>  - > 

<  -  450  Access  den1ed<CRLF> 

QUIT  <CRLF>  - > 

Server  closes  all 
connections. 


6.2  Connection  establishment.  The  FTP  command  connection  Is  established 
via  TCP  between  the  user  process  port  U  and  the  server  process  port  L.  This 
protocol  is  assigned  the  service  port  21  (25  octal),  that  Is  L-2L 
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1.  This  Military  Standard  Is  approved  for  use  by  all  Departments  and 
Agencies  of  the  Department  of  Defense. 

2.  Beneficial  conments  (recommendations,  additions,  deletions)  and  any 
pertinent  data  which  may  be  of  use  In  Improving  this  document  should  be. 
addressed  to:  Defense  Communications  Agency,  ATTN:  JllO,  1860  Wiehle  Avenue, 
Reston,  Virginia  22090,  by  using  the  self-addressed  Standardization  Document 
Improvement  Proposal  (00  Form  1426)  appearing  at  the  end  of  this  dociiaent,  or 
by  letter. 

3.  Because  of  the  rapid  development  In  this  standardization  area,  an 
alternative  method  of  conmunlcatlon  1$  offered.  Forward  responses  using  the 
MllNET  to  DCA*IAS  >  DCA-EMS.  Cooperation  of  the  user  Is  Important  to  make 
this  protocol  meet  DeoarbS^nt  of  Defense  needs. 
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FOREMORO 


This  docuMtnt  sptcifits  tht  S1i|>1t  Mill  Trinsfir  Frotocol  (SMTP),  i  protocol 
dMiqntd  to  trinsfir  •ill  rtllibly  ind  tfflclently.  Tht  docuiwit  includes  in 
introduction  to  SMTP  with  i  Model  of  operetion,  procedures,  end  specifici- 
tions,  including  stite  diegrias. 
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1.  SCOPE 

1.1  Purpost.  This  standard  establishes  crlttrli  for  the  Simple  »11 

Trwsfer  miocol  (SNTP),  a  protocol  designed  to  transfer  eall  reliably  and 
efficiently. 

1  i  Oroanlzatlon.  This  standard  Introduces  the  Sleple  Nall  Trwsfer 
PritLoPs'&friKl  procedures  In  sending  and  weWIng 
the  coaaands  «»d  other  nchanlsms  needed  to  support  SNTP.  This  standard  also 
describes  the  uses  of  SNTP  with  various  transport  services. 

1  >.i  Transoort  services.  One  of  the  eost  leportant  features  of  SNTP  Is 
Us  capabllRy^  relayMTl  across  transport  service  er.vlronnents.  A  trans¬ 
port  «rv1ce  provides  an  Interprocess  eo*in1cat1on  wvironwt  (1^).  to 
IPCE  way  covtr  m  nttiiork.  stvtral  nttiforfcSg  or  a  substt  of  a  nttiiork.  It  1$ 
iMortint  to  rtallzt  that  trwisport  systtas  (or  IPCCs)  art  not  ont-to -one  with 
networks.  A  process  can  coanunlcate  directly  with  another  process  through  any 
ewtHally  known  IPCE.  Nall  Is  an  application  or  use  of  1"t«r-pr^ss 
coMunIcatlon.  Nall  can  be  eo«un1cated  between  P^***** J" 
hv  rtlaylno  throuoh  a  proctss  conntcttd  to  two  (or  sort)  IPCCs-  Hort 
sptcifically.  «a11  can  bt  rtlaytd  bttwttn  hosts  or.  difftrtnt  transport  systtas 
by  a  host  on  both  transport  systtas. 

1.3  Application.  The  Sliole  Nall  Transfer  ^to«1 
all  OoO^ckti  sSTtchlng  nttworks  »^lch  coimtct  or  havt  tM 
utllUIng  eonneetivlty  Kross  netw^  and 

require  a  nail  transfer  service.  The  ter*  network  as  used  herein  includes 
Local  Area  Networks. 
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2.  REFERENCED  OOCUNENTS 

2-^  Of  <tocutnts.  The  following  dociMtnts  of  the  Issue  In  effect  on 

<l«te  of  invitetlon  for  bids  or  request  for  proposiL  for*  t  pert  of  this 
stendard  to  the  extent  specified  herein. 

STANDARDS 

FEDERAL 

FED-STD-1037  Glossary  of  TclecoMuilcatlon  Teras 

MILITARY 

MIL-ST0*1778  Transalsslon  Control  Protocol 

2*2  ^^^publlcatlons.  The  following  dociaents  fora  a  part  of  this 
standard  lo  the  extent  specified  herein.  Uiless  otherwise  Indicated,  the 
Issue  in  effect  on  date  of  Invitation  for  bids  or  request  for  proposal  shall 
•CPly.  (The  provisions  of  this  paragraph  are  under  consideration.) 
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3.  DKFINITXONS 

3.1  Dafloltlon  of  ttnw*  The  definition  of  tent  used  in  this  etanderd 
•hai  coaply  vdth  FED-STD-1037.  Tene  end  definitions  unique  to  M1L-ST*>-I781 
ere  contained  herein. 

a.  Coroand 

A  request  for  a  nail  aerviee  action  sent  by  the  aender-SMTP  to  the 
receiver-SKTP. 

b«  Donaln 

The  hierarchially  structured  global  diaraeter  string  address  of  a 
host  conputer  in  the  sail  systen* 

c.  End  of  nail  data  indication 

A  special  sequence  of  characters  that  indicatea  the  end  of  tha  mail 
data.  In  particular »  the  five  characters  carriage  return^  Una 
feed,  period,  carriage  return,  line  feed,  in  that  order. 

d.  Host 

A  conputer  in  the  intemetifork  environment  on  vhieh  nallboxas  or  SMTP 
proceaaet  reside. 

e.  tine 

A  sequence  of  ASCII  characters  ending  with  a  <CSL^>. 

f.  Mall  data 

A  sequence  of  ASCII  characters  of  arbitrary  length,  idiieh  conforms 
to  the  standard  eat  In  the  Standard  for  the  Pomat  of  AIPA  Internet 

Text  Messages. 

g.  Mailbox 

A  character  string  (address)  which  identifies  a  user  to  whom  nail 
is  to  be  sent.  Mailbox  normally  consists  of  tha  host  and  user 
specifications.  The  staidarl  nallbos  naming  convent Ion  Is  defined 
to  be  ^userSdonaln*.  Additioially.  wue  "contaic&r*  in  «dilch  mail 
is  stored. 

h.  Ieceiver"SMrP  process  __ 

A  process  «diich  transfers  msil  in  cooperation  with  a  sendar-SCTP 
process.  It  waits  for  a  connection  to  be  estabUshed  via  the 
transport  service.  It  receives  SMTP  comesnds  from  the  seoder*SMTP. 
sends  repUes.  and  perforas  the  specified  operations. 

1.  Etply 

A  rtprv  is  as  acknowledgment  (positive  or  negative)  sent  from  receiver 
to  sendee  via  the  transnission  channel  in  response  to  a  command.  The 
general  form  of  a  reply  is  a  conpletlon  code  Uncluding  arror  codas) 
followed  by  a  text  string.  The  codas  are  for  use  by  programs  and  the 
text  is  usually  intended  for  human  users. 
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J.  Scndcr^SMTP  proceii 

A  procets  which  traotftrs  a«ll  in  cooperation  with  a  receiwer-SMTP 
proceaa.  A  local  language  nay  be  uaed  in  the  uaer  interface 
connand/reply  dialogue.  The  aender-SMTP  Initiates  the  transport 
service  connection.  It  initiates  SMTP  connands,  receives  replies, 
and  governs  the  transfer  of  nail. 

k.  Session 

The  set  of  exchanges  that  occur  while  the  traosnission  channel  is 
open. 

l.  Transaction 

The  set  of  exchanges  required  for  one  nessage  to  be  tranenltted 
for  one  or  no re  recipients. 

n.  Transnisslon  channel 

A  full-duplex  connunication  path  between  a  sender-SHTP  and  a  recelver- 
SMTP  for  the  exehanfs  of  connands,  replies,  and  nail  text. 

n.  Transport  servlca 

Any  reliable  strec!«-orl anted  data  connunication  services.  For  exanple, 
MCP,  TCP,  Mns. 

o.  <CTI.y> 

file  cbaracters  carriage  return  and  line  feed  (In  that  order). 

p.  <SP> 

The  space  character. 


4 


MILITARY  STANDARDS:  SMTP 


MIL-STD  1781 


MIL-STD-1781 
10  May  1984 


4.  THE  SMTP  MODEL 

4.1  SMTP  detlgp.  The  SMTP  design  is  based  on  the  following  ondel  of  cowiu- 
nlcatlon:  as  the  result  of  a  user  nail  request,  the  sender-SMTP  establishes 
a  two-vay  transolsslon  channel  to  a  receive r-SMTP.  The  recelver-SMTP  coananda 
are  generated  by  the  aender-SMTP  and  sent  to  the  recelver-SMTP.  SMTP  replies 
are  sent  from  the  recelver-SMTP  to  the  aender-SMTP  In  response  to  the  comands. 

4«1.1  Hall  coanand*  Once  the  tranaalsslon  channel  Is  established,  the  SMTP- 
sender  sends  a  MAIL  coassind  Indicating  the  sender  of  the  Ball*  If  the  SNTP- 
receiver  can  accept  aall  It  responds  with  an  OR  reply*  The  SMTP-tender  than 
sends  a  RCPT  conand  Identifying  a  recipient  of  the  sail.  If  the  SHTP-recelver 
can  accept  wall  for  that  recipient  It  responds  with  an  OR  reply;  If  not.  It 
responds  with  a  reply  rejecting  that  recipient  (but  not  the  whole  Ball  trans¬ 
action).  The  SMTP-sender  and  SMTP-recelver  Bay  negotiate  several  recipients. 
Vhen  the  recipients  have  been  negotiated  the  SHTP-sender  sends  the  Ball  data, 
tenilnatlng  with  a  special  sequence.  If  the  SMTP-racelver  successfully  pro¬ 
cesses  the  Ball  data  It  responds  with  an  OR  reply.  The  dialog  Is  purposely 
lock-step,  one-at-a-tlae. 


StNOtSaWTS  MCIIVDI-SMTP 


FIGURE  1.  Model  for  SMTP  use. 

4.1.2  TransBlsslon  of  Ball.  The  SMTP  provides  Bschanlsas  for  the  trsos- 
Blsslon  of  Ball;  directly  froa  the  sending  user's  host  to  the  receiving 
user's  host  when  the  two  hosts  are  connected  to  the  ssbs  transport  service, 
or  via  one  or  aore  relay  SMTP-servers  when  the  source  and  destination  Hosts 
are  not  connected  to  the  sane  transport  service.  To  be  able  to  provide  the 
relay  capability,  the  SMTP-servar  Bust  be  supplied  with  the  naat  of  the 
ultlaate  destination  host  as  well  as  the  destination  Bsllbox  naae. 

4.1.2. I  Forward-  and  reverse-path.  The  arguaent  to  the  MAIL  coBaand  Is 
a  reverst-path,  wk»ich  specifies  who  the  aail  is  froa.  The  arguaent  to  the 
RCPT  eoeaand  Is  a  forward-path,  which  specifies  who  the  Ball  is  to.  The 
forward-path  Is  a  source  route,  while  the  reverse-path  is  a  return  route 
(which  aay  be  used  to  return  a  aessage  to  the  sender  when  an  error  occurs 
with  a  relayed  aessage). 
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Multiplji  fclplgnf «  Whan  tht  mm  aetMga  la  Mnt  to  miltlplo 
roclpionta  tho  SMTP  •neourageo  tht  trantsioolon  of  only  ont  copy  of  tht  data 
for  all  tht  rtclpitnta  at  tht  mm  dtatlnatlon  hoot* 

^•1*3  Mall  ayntaa^  Tht  Mil  cowanda  and  rtpllta  havt  a  rigid  ayntax* 
Rtpllta  alao  havt  a  nuMrlc  coda.  Tht  following  txaaplta  um  actual  eoMModa 
and  rtpllta*  Tht  conplttt  llata  of  cooaanda  and  rtpllta  appMra  In  Stetlon  4 
on  aptclflcatlona*  CooModo  mod  rtpllta  art  not  com  Mnaiv.lrt*  That  la, 
a  coMand  or  rtply  word  My  bt  upptr  caat,  lowtr  eaat,  or  any  alxtura  of  upptr 
and  lower  eaat*  Kota  that  thla  la  not  trua  of  Mllbox  uMr  otMa*  For  aoaa 
hoata  tht  uatr  oaM  la  eaat  atnaltltt,  and  SNTP  InpltMntatlooa  Mat  raVt  eaat 
to  prtatrvt  tht  eaat  of  uMr  ntMo  at  thty  appear  In  Mllboz  arguMiiCa.  loat 
ntMa  art  not  eaat  Moaltlvt.  Co—anda  and  rtpllta  art  co^oatd  of  eharaeCtrt 
fron  tht  ASCII  charaettr  Mt*  Whtn  tht  tranaport  Mnrlet  prorldta  an  8-blt 
byta  (octet )  trananlaalon  channel ,  each  7-blt  charaettr  la  tranaaltttd  right 
juatlfltd  la  an  octat  with  the  hl^  ordtr  bit  clMrtd  to  atro*  Whtn  aptcl- 
fylng  the  gtntral  fom  of  a  conMnd  or  rtply,  an  arguMnt  (or  aptelal  ayahol) 
will  bt  denoted  by  a  Mta-llngulatlc  variable  (or  eonatant),  for  txan^lt, 
*^<atrlng>''  or  ''<rtvtrat-path>**  Bert  the  angle  braeketa  Indicate  thtM  art 
■eta-llngulatic  varlablta*  However,  aoM  argunenta  um  tht  angle  braeketa 
literally.  For  txaiplt,  an  actual  rtvtrae-ptth  la  tnelottd  In  angle  braeketa, 
!»•••  **<John.SnlthfUSC*XSI.IUlFA>''  la  an  Inatance  of  <rtvtrat*ptth>  (tht 
braeketa  art  actually  trananitttd  In  tht  coMuind  or  reply). 
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S.  THE  SMTP  PROCEDURES 

5*1  Introduction.  Thit  Mctlon  protonts  tho  procodurot  used  in  SMTP  in 
Mvtral  parti.  Pint  comi  tha  baaic  sail  procadura  dafinad  aa  a  sail  trana** 
action.  FoUoiring  thia  ara  daacriptiona  of  forwarding  nail,  varifying  aailbos 
naaaa  and  axpanding  wailing  liata,  landing  to  tarwinala  inataad  of  or  in  cow- 
bination  with  wailboaaa,  and  tha  opaning  and  cloaing  axchangaa.  At  tha  and 
of  thia  aaction  ara  eoManta  on  rallying,  a  nota  on  wail  doaainr,  and  a  dia- 
euaaion  of  changing  rolaa.  Throughout  thia  aaction  ara  azanplta  of  partial 
coaaand  and  reply  aaquancaa. 

5.2  Mail.  There  ara  three  atapa  to  SMTP  wail  tranaactiona.  Tha  trana* 
action  ia  atartad  with  a  NAIL  eoaaand  Which  giwaa  tha  aandar  identification. 

A  aariaa  of  one  or  wore  RCPT  cowaanda  followa  giwing  tha  receiver  infoma-* 
tioa.  Than  a  DATA  eoanand  givaa  tha  aail  data.  And  finally,  tha  and  of  nail 
data  indicator  confine  tha  tranaaction. 

5.2.1  MAIL  co^nd.  Tha  firat  atap  in  tha  procedure  ia  the  NAIL  cowaand. 
Tha  <ravaraa-path>  containa  tha  aourca  wailbox. 

HAIL  <SP>  ?ROM:<ravaraa*-path>  <CRLF> 

Thia  coaRind  talla  tha  SNTPTacaifar  that  a  new  aail  tranaaction  ia  atarting 
and  to  raaat  all  ita  atata  tablaa  and  buff ara,  including  any  racipianta  or 
aail  data.  It  givaa  tha  ravaraa«-path  which  can  be  uaed  to  report  errora. 

If  accepted,  tha  recaiver-SMTP  returna  a  2S0  OR  reply.  The  <raTerae-p*th> 
can  contain  aora  than  juat  a  aailbox.  Tha  <reverae-path>  la  a  reweraa 
aourca  routing  liat  of  hoata  and  acuree  aailbox.  The  firat  heat  In  the 
<raveraa-path>  ahould  be  the  hoat  lending  thia  coaaand. 

5.2.2  RCPT  coaaand.  The  aacond  atap  in  the  procedure  la  the  RCPT  coaaand. 

RCPT  <8P>  TOi  <f orward-patb>  <CRLP> 

Thia  coanand  givaa  a  focward*^th  identifying  one  recipient.  If  accepted, 
tha  reeaiver'*SNTP  ratuma  e  250  OR  reply,  and  atoraa  the  forward-path.  If 
the  racipiavit  ia  unkaown  the  recaiver*SMTP  ratuma  a  550  Pailura  reply. 

Thia  aacond  step  of  the  procedure  can  be  repeated  any  nuaber  of  tiaea.  The 
<foiward-path>  can  contain  aora  than  juat  a  aailbox.  The  <foiward*path>  ia 
a  aourca  routing  liat  of  hoata  and  the  deatination  aailbox.  The  firat  hoat 
in  the  <forward'n;>aCh>  should  be  tha  hoat  receiving  thia  coaaand. 

5.2.3  DATA  coaaand.  The  third  atap  in  the  procedure  ia  the  DATA  coaaand. 

DATA  <CRLP> 

If  accepted,  the  racaiver-SNTP  ratuma  a  354  Interaadiata  reply  and  cooaidara 
all  aucceading  lines  to  ba  tha  aaaaage  text.  Hhen  the  end  of  text  ia  received 
and  stored  tha  SMTP*recalver  sands  a  230  OR  reply.  Since  the  aail  data  ia 
sent  on  tha  tranaaisaioa  channel  the  and  of  tha  aail  data  auat  ba  indicated 
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to  that  the  canund  and  reply  dialog  can  be  retuaed.  SKTP  iidicatet  the  end 
of  the  Mil  data  by  tending  a  Une  containing  only  a  period.  A  trantparency 
procedure  it  uted  to  prevent  thit  froa  interferii«  vith  the  uter't  teat  (tee 
Section  4.5.2).  The  end  of  aail  data  indicator  alto  confirat  the  mil  trent- 
action  and  telle  the  receivet^SMTP  to  noe  procett  the  atored  reclpientt  end 
mil  data.  If  accepted,  the  receiver-SKTP  returm  a  250  OK  reply.  The  DATA 
coamnd  ahould  fail  only  if  the  aail  traneection  wet  incoaplete  (for  exeaple. 
no  reclpientt).  or  if  retourcea  are  not  available. 

5.2.4  Synoptit.  The  above  procedure  it  an  exeaple  of  a  aail  trenaaetion. 
Thete  coamndt  autt  be  uted  only  in  the  order  diacutaed  above.  Paragraph 
5.2.5  illuatratet  the  uae  of  thaae  coamndt  in  a  aail  tramaetion. 

^.2.5  Exaaple  of  the  SKTP  procedure.  Thit  SMTP  exeaple  ahowa  mil  tent  by 
Saith  at  boat  AlpU.ARPA.  to  Jonee.  Green,  and  Broun  at  hoat  Beta.AltPA.  Rare 
ve  eaaum  that  hoat  Alpha  contacta  boat  Bate  directly. 

S:  MAIL  PROH:<SBith9AlphaJlBPA> 

R:  250  GR 


S:  RCPT  1D:<JoneefBeta.AtPA> 
R:  250  OR 

S:  RCPT  TOi<Creen|RetaJiRPA> 
R:  550  No  auch  ueer  hare 

S:  RCPT  T0{<Bro«miBeta.ARPA> 
R:  250  OR 


S:  DATA 

R:  354  Start  aail  ii^ut;  ei4  vlth  <CRLP>.<CRLF> 

S:  BUh  bUh  bUh... 

S:  ...etc.  etc.  etc. 

S:  <CRLP>.<CRLP> 

R:  250  OR 

The  aail  hat  now  been  accepted  for  Jonea  and  Brown.  Green  did  not  have  a 
aatlbox  at  hoot  Beta. 

P^nrarding.  There  ere  eom  ceaea  where  the  deatinatlon  information 
in  the  <forward-path>  it  incorrect,  but  the  receiver*BKXP  knowa  t\m  correct 
deatinatlon.  In  auch  cates,  one  of  the  followli^  repliea  ateuld  be  used  to 
allow  the  tender  to  contact  the  correct  deetination. 

a.  251  Uaer  not  local;  will  forward  to  <forward*path>.  Thit  reply 
indlcatea  that  the  receiwar-SMTP  kaowa  the  near* a  mllhox  it  on 
another  hoat  end  indlcatea  the  correct  forward-path  to  uae  in  the 
future.  Note  that  either  the  hoat  or  uaer  or  both  my  be  differ¬ 
ent.  The  receiver  takea  ret pone ibility  for  deli verify  the  meaeage. 
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b*  551  Uitr  not  local;  pltaaa  try  <£onrard-path>.  Thla  reply  Indi- 
caett  that  the  racalvtr-SMTP  knowt  tha  uaar'a  nallbox  if  on 
another  hoot  and  Indlcatea  the  correct  forward-path  to  uee.  Note 
that  either  the  boat  or  uter  or  both  nay  be  different.  The  re- 
eelvei  refiiaea  to  accept  mall  for  this  uaer,  and  the  aender  nuat 
•Ither  redirect  the  nail  according  to  the  information  provided  or 
return  an  error  reaponae  to  the  originating  uaer. 

Paragraph  5.3.1  llluatratea  the  uae  of  theae  reaponaea. 


5.3.1  Kna»le  of  forwardi^.  *ltheri 

8:  tCPT  TO:<PoatelfOSC-ISI.ARPA> 

t:  251  Uaer  not  local;  will  foeward  to  <Poatel§USC-ISlF.ARPA> 


Or: 

S:  ICPT  TO;<PattlfUSC-IStl.ARPA> 

tx  551  Uaer  not  local;  pleaae  try  <Mockapetrla#USC-lSIF.ARPA> 

S.i  Verlfvlnt  and  enpandlng.  SKTP  provldea  aa  additional  featurea,  con- 
to  verily  •  uaer  nane  or  expand  a  mailing  Hat.  Thla  la  done  with  the 
nPT  ai^  IXW  c^/mamnda,  which  have  character  atrlng  arguaanta.  For  the 
coo«and.  the  atrlng  la  a  uaer  name,  and  tha  reaponae  may  Include  the  fall 
ntm  of  tha  uaer  and  muat  Include  tha  mailbox  of  tha  uaer.  For  the  tXPN 
coa«aod.  the  atrlng  Identlflea  a  mailing  Hat,  and  tha  mmltlUne  reaponae 
may  Include  the  full  nami  of  the  uatra  and  muat  give  the  mallboxaa  on  the 
mailing  Hat.  "Uaer  name*  la  a  fuaay  term  end  uaed  purpoaely*  If  a  boat 
ImnleMnta  the  PIFT  or  iXPli  commanda  then  at  leant  local  mallboxaa  muat  be 
recognlied  aa  •uaer  namea*.  Xf  a  boat  chooaea  to  recognlae  other  atrlnga  et 
•uaernamaa*  that  la  allowed.  Xn  aoma  hoata  the  dlatlnctlon  between  a  mak¬ 
ing  Uat  and  an  allaa  for  a  alngle  mailbox  la  a  bit  fuaay,  alnce  a  common 
data  atructure  may  hold  both  typea  of  entrlea,  and  It  la  poaalble  to  have 
mailing  llata  of  one  mailbox.  Xf  a  re^ueat  la  made  to  verify  a  mailing 
llgt,  a  poaltlve  reaponae  can  be  given  If  on  receipt  of  a  meaaage  ao 
addreaaed  It  will  be  delivered  to  everyone  on  the  Uat,  othervlae  an  error 
ahould  be  reported  (e.g.,  *550  That  la  a  mailing  Uat,  not  a  uaer").  li  * 
re^ueat  la  made  to  expand  a  uaer  name  a  poaltlve  reaponae  can  be  formed  by 
returning  a  Uat  containing  one  name,  or  an  error  can  be  reported  (e.g., 

•550  That  la  a  uaer  name,  not  a  mailing  Uat*).  Xn  the  caae  of  a  multi- 
line  reply  (normal  for  fXPli)  exactly  one  mailbox  la  to  be  apeclfled  on  each 
Une  of  the  reply.  Xn  tha  caae  of  ao  amblguoua  requeat,  for  exanple,  •VtFT 
Smith*,  where  there  are  two  Smlth'a  the  reaponae  muat  be  *553  Uaer  amblguoua*. 
The  of  verifying  a  uaer  naam  la  atralght forward  aa  ahown  la  paragraph 
5.4.1. 


5.4.1 


^e  of  verifying  a  uaer 


tither: 


Si  ftPT  Smith 

it  250  Pred  Smith  <Smlth90SC-XSlP.AiPA> 
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Or: 

S:  VRFY  Saith 

R:  251  Uter  not  local;  will  forward  to  <S]BlthfUSC-ISlQ.ARPA> 

Or: 

S:  VRFY  Jones 

R:  550  String  does  not  match  anything. 

Or: 

S:  VRFY  Jonas 

R:  551  User  not  local;  pXaaea  try  < Jonas fUSC-IS IQ. ARPA> 

Or: 

S:  VRFY  GourstTtikyinplatt 
R:  553  Uatr  aablguoua. 

5.4*2  Eaaapla  of  axpandlng  a  aalling  list.  Tht  cast  of  axpandlng  a  aall* 
boa  list  requires  a  ■ultlllne'raply  as  althar: 

S:  EXPN  ExaaplfPeopla 

R:  250-Joo  Postal  <Postal9USC-lSlP.AEPA> 

R:  25C>-Frad  Pontbona  <Fonabona|USC-lSlQ.ARPA> 

R:  250-Saa  Q.  Smith  <SQ$mith9U$C*lSIQ.AJtPA> 

R:  25(KQuiney  Smith  <9USC-ISlP.ARPA:Q-Smith9ISX-VAU.ARPA> 

R:  250’-<joa9foo"*unlx.ARPA> 

R:  250  <xys9bar*unix.ARPA> 

Or: 

$:  EXPN  £xacutlva*4fashrooa-Ust 
R:  550  Access  Denied  to  You. 

5.4.3  Chyacter  string  arguments.  The  character  string  arguments  of  the 
VRFY  and  commands  cannot  be  further  restricted  due  to  the  variety  of 
implementations  of  the  user  name  and  mailbox  list  concepts.  On  some  systems 
it  may  be  appropriate  for  the  argument  of  the  EXPN  cemomnd  to  he  a  file  mams 
for  a  file  containing  a  mailing  list,  but  again  there  is  a  variety  of  file 
naming  conventions  in  the  Internet.  The  VRFY  and  EXPN  commands  are  not  in* 
eluded  in  the  minimum  implementation  (paragraph  6.5.1)  ai^  are  not  required 
to  work  across  relays  when  they  are  iaplemenced. 

5.5  Sending  and  mailing.  The  main  purpose  of  SMTP  is  to  deliver  messages 
to  uaer^s  mailboxes*  A  very  slmiler  service  provided  by  some  hosts  la  to 
deliver  messages  to  ueer*a  terminals  (provided  the  user  is  active  on  the 
host).  The  delivery  to  the  user's  mailbox  is  called  *melllng,*  the  delivery 
to  the  user's  terminal  la  called  "sending.*  iecause  in  many  hosts  the  laple* 
mentation  of  sending  is  nearly  identical  to  the  implement at ion  of  mailing 
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5.6.2  ExupIc  of  copiwctlop  cloilni* 


221  BB1I-9NZX.A11FA  Service  elotlog  trtMalatloii  ehaaiMl 


5.7  Rtlsying.  Tht  forwtrd*p«tb  asy  b«  a  tourea  route  of  tha  fora 
"^ONE . (ITVO: Jb^iTHREE*' ,  vhara  ONE.  TVO,  and  TMtSE  are  boata.  Thia  fora  la 
uaad  to  anpbaaita  tba  diatlnctlon  batvaan  an  addraaa  and  a  routa.  Tba  sail- 
box  la  an  abaoluta  addraaa,  aid  tba  routa  la  inforration  about  bow  to  fat 
tbara.  Tha  two  eoneapta  abould  not  ba  confuaad.  Coaeaptually ,  tba  alaaanta 
of  the  forvard'-patb  ara  sovad  to  tha  ravaraa-pafb  aa  tba  Maaaga  la  relayed 
froa  one  sarvar-SMTP  to  anotbar.  Tba  ravaraa-patb  la  a  rawaraa  aourca  routa 
(l.a.,  a  aourca  routa  frou  tba  currant  location  of  tba  Maaaga  to  tba  origi¬ 
nator  of  tba  Maaaga).  Vban  a  aarvar-8MTF  dalataa  Ita  Idaatlflar  frow  tba 
forward-path  and  Inaarta  it  Into  tba  ravaraa-patb.  It  auat  uaa  tba  naM  It 
la  known  by  in  tba  anvlronMnt  It  la  aandlng  Into,  not  tba  anvlronMnt  tba 
Mil  caM  froo,  In  caaa  tba  aanrar-SKTF  la  known  by  dlffarant  naMa  In 
dlffarant  anvlronMnta. 


5.7.1  Maaaaia  arrival.  If  whan  tba  Maaaga  arrlwaa  at  tba  flrat 

aloMnt  of  tba  forward-path  la  not  tba  Idantlflar  of  that  SMTf  tba  alOMOt 
la  not  dalatad  frou  the  forward-path  and  la  UMd  to  dataralM  tba  nazt 
8HTP  to  aand  tba  Maaaga  to.  In  any  caaa,  tba  SKT?  adda  Ita  own  Idantlflar 
to  tba  ravaraa-patb.  Oalng  aource  routing  tba  rncalwar-BITf  rnealwna  mU 
to  ba  ralayad  to  anotbar  aarvar-dKTP.  Tba  racalwar-SNnP  My  accept  or  ra- 
jact  tba  taak  of  relaying  tba  Mil  In  tba  aara  way  it  accapta  or  rajacta 
Mil  for  a  local  uaar.  Tba  racalvar-MTP  traraforM  tba  conaMnd  arguMnta 
by  Mwlng  Ita  own  Idantlflar  fron  tba  forward-path  to  tba  beginning  of  tba 
ravtraa-patb.  Tba  racalvar-IKT?  than  bacoMo  a  aandar-fMTr,  aatabllabaa 
a  trananlaalon  ebannal  to  tba  next  BCTF  In  tba  foniard-patb,  and  aanda  it 
tba  Mil. 


5.7,2  rirat  boat  Idwlflcatli^  Tba  flrat  boat  In  tba  rawaraa-patb 
abould  ba  tba  'boat  aandlng  t^  WTr  coiwaanda,  and  tba  flrat  boat  la  tba 
forward-path  abould  ba  tba  beat  racalwing  tba  MTT  cenModa*  Motlca  that 
tba  forvard-patb  and  ravaraa-patb  appear  In  tba  SNTP  cn—anda  and  rapllaa, 
but  not  nacaaaarlly  In  tba  Manage.  That  la,  tbara  la  m  naad  for  tbaaa 
patba  and  aapacially  tbla  ayntax  to  appear  In  tba  *Tot,*  Treat,*  *CCt,* 
ate.,  fialda  of  tba  ncaaaga  bandar.  If  a  aarwar-SNTF  baa  accepted  tba 
taak  of  relaying  tha  Mil  and  latar  flnda  that  tba  forward-path  la  Incor¬ 
rect  or  that  tba  Mil  cannot  ba  dallwarad  for  wbatawar  raaaon,  than  It 
nuat  conatruet  an  'undallvarabla  Mil*  notification  Maaaga  and  Mnd  it  to 
tha  originator  of  tba  undalivarabla  Mil  (aa  Indicated  by  tba  rawarna-patb) • 


5.7.3  Prawantion  of  lype  In  arrar  report ly.  Tbla  notification  Manage 
Mat  ba  free  tKa  aarvar-SNn  at  t^la  boat.  Of  couraa,  aarvar-SNTPa  abould 
not  aand  notification  Moaagaa  about  probloM  with  notification  Maaagaa. 

Ona  way  to  prawant  loopa  in  error  reporting  la  to  apaclfy  a  null  rawaraa- 
path  in  tha  HAIL  coMand  of  a  notification  Maaaga*  Vban  aucb  a  Manage 
in  ralayad  it  la  paralaalbla  to  laava  tba  rawaraa*>ttb  noli.  A  NAIL  c  cum  ml 
with  a  null  raaaraa-patb  appaara  aa  NAIL  Pt0N;O.  Aa  undallwarabla  Mil 


mm 
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thaaa  two  functions  sro  coablnod  In  SMTP.  Howovor  tho  oondinf  coBoando  sro 
not  Includod  In  tho  rtqulrod  BlnlauB  loploBontotlon  (psrsgroph  6.S.1).  Usors 
should  hsvo  tho  oblllty  to  control  tho  writing  of  Msssgos  on  thoir  torsinols. 
Most  hosts  porsit  tho  usors  to  sccopt  rofuso  such  wossogos.  Tho  following 
throo  coBBsnds  sro  dofinod  to  support  tho  sending  options.  Thoso  sro  usod  in 
tho  Mil  trtnsoction  instosd  of  tho  NAIL  coomnd  sod  infor«  tho  rocoivor-SMTP 
of  tho  spocitl  soMntics  of  this  tronssetion: 

t.  SEKO  -:SP>  ntOM:<rovorso-poth>  <C1LF>.  Tho  SBHD  coMsnd  roquiros 
that  tho  Mil  data  bo  dolivorod  to  tho  usor's  torvinal.  If  tho 
usor  is  not  actieo  (or  not  accopting  torninal  Mssagos)  on  tho 
host  a  4S0  roply  My  rotum  to  a  KCFT  coMond*  Tho  Mil  trans* 
action  is  successful  if  tho  Mssago  is  dolivorod  to  tho  totBinal. 
Tho  SOM  roply  code  which  is  used  for  tho  NAIL  coBMnds  is  used 
for  this  coMsnd. 

b.  SONL  <SP>  PllOM:<rovorso*path>  <CRLP>.  Tho  SEND  or  MAIL  coMsnd 
requires  that  tho  Mil  data  bo  dolivorod  to  tho  usor's  torvinal 
if  tho  usor  is  active  (and  accopting  terminal  Mssagoa)  on  tho 
host*  If  tho  usor  is  not  active  (or  not  accopting  terminal 
MSsagos)  than  tho  Mil  data  is  ontorod  into  tho  user's  Milbox. 
Tho  Mil  transaction  is  successful  if  tho  message  is  dolivorod 
either  to  tho  terminal  or  tho  Milbox.  Tho  som  roply  code 
Which  is  usod  for  tho  NAIL  commands  is  usod  for  this  comMod. 

c.  8ANL  <8P>  FIOHx  <rovorso*-path>  <C8LF>.  Tho  88IID  and  NAIL  cooMnd 
roquiros  that  tho  Mil  data  bo  dolivorod  to  tho  usor's  tominal 
if  tho  usor  is  oetivo  (and  accopting  torminal  Mssagos)  on  tho 
host.  In  any  case  tho  Mil  data  is  ontorod  into  tho  usor's 
Milbox.  Tho  Mil  transaction  is  successful  if  tho  Msaago  is 
dolivorod  to  tho  Milbox.  Tho  som  roply  code  which  is  usod  for 
tho  NAIL  cooMods  is  used  for  this 

5.8  Oponini  and  closing*  At  tho  tioo  tho  transmission  channol  is  opened 
there  is  an  exchange  to  oMuro  that  tho  hosts  are  communicating  with  tho 
hosts  they  think  they  are*  Tho  following  two  comMnds  are  usod  in  transmis* 
Sion  channol  opening  and  closing: 

s.  MELO  :%f>  <deMia>  <C1LLP> 

b.  QDiT  <au.f> 

In  tho  MELO  comMnd  tho  host  sending  tho  comnsnd  idontifioa  itMlf:  tho  com* 
Mod  My  bo  intorprotod  as  saying  *‘Mollo,  I  am  <doMin>‘’. 

5.8.1  Exsmplo  of  connection  opening. 

t:  120  l•N-UNIX.AEPA  Siiplo  Nail  Transfer  Service  koady 

S:  MELO  0SC*lSXrJlKPA 

1:  250  iMI-UlClX.AEPA 
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aotification  attsafa  la  ahown  la  paragraph  S.7,4.  Thla  aotlflcatlon  la  in 
raaponaa  to  a  Baataga  orlginatad  hj  JOE  ac  HOSTV  and  aanc  via  KOSTX  to  KOSTY 
with  lastruetlena  to  ralay  It  on  to  HOSTZ*  What  we  aaa  la  tha  axaopla  la 
tha  tranaaetlon  batwaan  HOSTY  and  MOSTX,  which  la  tha  flrat  atap  In  the  raturn 
of  tha  notification  aaaaaga. 

5«7.4  Baaipla  of  an  uadallvarabla  aall  aotlflcatlon  aaaaaga. 

8:  MAIL  riONiO 
R:  2S0  ok 

St  RCPT  lD:<tH0STX.AKPA:J0E8H0STW.ARPA> 

R:  2S0  ok 
S:  DATA 

R:  354  aand  tha  aall  data,  azid  with  • 

8:  Data:  23  Oct  81  11:22:33 
8:  Froa:  SKYPtHOSTY .ARPA 
8:  To:  JOEfHOSTV.AlPA 
8:  Subjact:  Mall  Syataa  Problaa 
8: 

8:  Sorry  JOE,  your  aaaaaga  to  SAMfHOSTZ .ARPA  loat. 

8:  iiOSTZ.ARPA  aald  thla: 

8:  **550  He  Such  Dear" 

8:  • 

R:  250  ok 

Ooaalfia  ara  a  racantly  Introduced  eoaeapt  la  tha  ARPA  latar- 
aat  aall  ayataa.  Tha  uaa  of  doaalaa  chaagaa  tha  addraaa  apace  froa  a  flat 
global  apace  of  alapla  character  atrlag  boat  naaaa  to  a  hierarchically  atruc* 
turad  rooted  tree  of  global  addraaaaa.  Tha  hoat  naaa  la  replaced  by  a  doaaln 
and  hoat  daalgnator  which  la  a  aaquanea  of  doaaln  alaaaat  atrtnga  aaparatad 
by  parloda  with  tha  uadarataadlng  that  tha  doaaln  alaaanta  ara  ordered  froa 
tha  aoat  apaclflc  to  tha  aoat  general*  for  aaaapla,  "USC^XSIP.ARPA*, 
*Prad.Caabrldfe.UK*',  and  "PCJ.LCS.  NIT  .ARPA*  eight  ha  hoat-aad-doaain  Idantl* 
flora,  tfhanavar  doaaln  naaaa  ara  uaad  In  SMTP  only  tha  official  naaaa  ara 
uaad,  tha  uaa  of  nlekaaaaa  or  aUaaaa  ara  aot  allowed. 

5*9  Changlag  rolaa.  Tha  TUIH  coaaand  any  be  uaad  to  ravaraa  the  rolaa  of 
tha  two  prograaa  coaaunlcatlng  over  tha  tranaaiaalon  channel.  If  pfograa*A 
la  currently  tha  aendar^SMYP  and  It  aanda  tha  THRU  coaaand  and  racalvaa  an 
ok  reply  (250)  than  prograa*A  becoaaa  tha  racalver-SNIP*  If  prograa-R  la 
currently  tha  receive r-*SMTP  and  It  racalvaa  tha  TtfRH  coaaand  and  aanda  an  ok 
reply  (250)  thaa  prograa^R  baeoaea  tha  aandai^SMTP. 

5*9.1  Rafuaal  to  change  rolaa.  To  rafuaa  to  change  rolaa  the  rtcalvar 
aanda  tha  ^0l  reply.  Plaaaa  note  that  thla  coaaand  la  optional.  It  would 
aot  normally  be  uaad  in  altuatlona  where  tha  tranaaiaalon  channel  la  TCP. 
However,  when  tha  coat  of  aatabUahlng  tha  tranaaiaalon  channel  la  high, 
thla  coaaand  aay  be  quite  uaeful.  Per  axaapla,  thla  coaaand  aay  be  uaaful 
la  aupportlng  tha  aall  aaehanga  ualng  tha  public  awitchad  talaphona  system 
aa  a  tranaaiaalon  channel,  aapaclally  if  aoaa  hetta  poll  other  boats  tor 
aall  eachaagaa. 
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6.  THE  SNTP  SPECIFICATIONS 

6.1  SMTP  coa—ndt. 

6.1.1  Co—nd  ntict»  The  SMTP  conaende  define  the  aell  transfer  or 
the  asil  eyttea  function  requested  by  the  user.  SMTP  coaasnds  are  character 
strings  teralnated  by  <CRLP>.  The  coaaand  codes  thaaaelvas  are  alphabetic 
characters  teralnated  by  <SP>  If  paraaeters  follow  and  <CRLF>  otherwise*  The 
syntax  of  aallboxes  aust  confora  to  receiver  site  conventions.  The  SMTP  cos* 
aands  are  discussed  below.  The  SMTP  replies  are  discussed  in  the  Section  4*2* 
A  nail  transaction  involves  several  data  objects  which  are  cowunlcated  as 
arguaents  to  different  coaaands*  The  reverse^ath  Is  the  arguaent  of  the 
MAIL  coaaand »  the  forvard*path  Is  the  arguaent  of  the  KCPT  coaaand,  and  the 
nail  data  is  the  arguaent  of  the  DATA  coaaand.  These  arguaents  or  data 
objects  ausc  be  transaitted  and  held  pending  the  conflraatlon  coaaunlcated 

by  the  end  of  nail  data  indication  which  finalises  the  tranaactlon.  The 
Bodel  for  this  is  that  distinct  buffers  are  provided  to  held  the  types  of 
data  objects,  that  is»  there  is  a  reverse*path  buffer,  a  forward'^tb 
buffer,  and  a  nail  data  buffer.  Specific  coaaands  cause  inforastion  to  be 
appended  to  a  specific  buffer,  or  cause  one  or  aore  buffers  to  be  cleared. 

6.1.1.1  HELLO  (HELP).  This  coaasnd  Is  used  to  identify  the  sender^fiftP 
to  the  receiver-SliTV.  the  arguaent  field  contains  the  host  naae  of  the 
sender*SMTP.  The  reeeiver*SKTP  identifies  itself  to  the  sender«flfTP  la  the 
connection  greeting  reply,  and  in  the  response  to  this  coaaand.  This  eoa* 
aand  and  an  OK  reply  to  It  conflra  that  both  the  sender*SlfTP  and  the  receiver* 
SMTP  are  in  the  initial  state,  that  is,  there  is  no  traoaaetloa  la  progress 
and  all  state  tables  and  buffers  are  cleared. 

^*^*^*^  H41L  (MAIL).  This  coaaand  is  used  to  initiate  a  Mil  trans* 
action  in  which  the  Mil  data  is  delivered  to  one  or  aore  Milboses.  The 
arguaent  field  contains  a  reverse-path.  The  reverse-path  consists  of  an 
optional  list  of  hosts  and  the  sender  Mllbox.  When  the  list  of  hosts  la 
present,  it  is  a  ^reverse*  source  route  and  indicates  that  the  Mil  was  re¬ 
layed  through  each  host  on  the  Hat  (the  first  host  in  the  list  was  the  aoet 
recent  relay).  This  list  is  used  as  a  source  route  to  return  non-delivery 
notices  to  the  sender.  As  each  relay  host  adds  itself  to  the  beginning  of 
the  list,  it  aust  use  its  nsM  as  known  in  the  IPCE  to  which  it  is  relaying 
the  aail  rather  than  the  IPCC  froa  which  the  Mil  com  (if  they  are  differ¬ 
ent).  In  SOM  types  of  error  reporting  Mssages  (for  exaaple,  undeliverable 
aall  notifications)  the  reverse-path  My  be  null  (see  paragraph  S.7.4)* 

This  coaaand  clears  the  reverse-path  buffer,  the  forward-path  buffer,  and  the 
aail  data  buffer:  and  inserts  the  reverse-path  inforMtlon  froa  this  coMand 
into  the  reverse-path  buffer. 

6. 1.1.1  RECIPICHT  (KCPT).  This  coMsnd  is  used  to  identify  an  individual 
recipient  of  the  Mil  data;  aultiple  recipients  are  specified  by  aultiple 
use  of  this  coaMnd.  The  forward-path  consists  of  sn  optional  list  of  boots 
and  a  required  dtsrlnatlon  Mllbox.  Uhen  the  list  of  hosts  is  present.  It 
is  a  source  route  and  indicates  that  the  Mil  aust  be  relayed  to  the  next 
Host  on  the  list.  If  the  receiver-SKTP  does  net  lapleMnt  the  relay  function 
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It  Miy  use  the  saiee  reply  U  would  for  an  unknown  local  user  (550).  When  leall 
Is  relayed,  the  relay  host  must  remove  Itself  from  the  beginning  forward-path 
and  put  Itself  at  the  beginning  of  the  reverse-path.  When  mail  reaches  its 
ultimate  destination  (the  forward-path  contains  only  a  destination  mail-box), 
the  receiver-SNTP  inserts  it  into  the  destination  mailbox  in  accordance  with 
its  host  mail  conventions.  For  example,  mail  received  at  relay  host  A  with 
arguments 


FRON : <US£RXiHOST  Y . ARPA> 

TO : <iH0STA . ARPA .fHOSTB . ARPA : USERCfHOSTO . ARPA> 
will  be  relayed  on  to  host  8  with  arguments 

FROM : <#H0ST A .ARPA; USCRXfHOST  Y . ARPA> 

TO : <#HOST8 . ARPA ; USCRC8HOSTO . ARPA> . 

This  command  causes  its  forward-path  argumtnt  to  be  appended  to  the  forward- 
path  buffer. 

8. 1.1. 4  DATA  TDATAl.  The  receiver  trtats  the  lints  folUwing  the  coiMMnd 
as  mail  data  from  the  sender.  This  command  causes  the  mail  data  from  this 
command  to  be  appended  to  the  mail  data  buffer.  The  mail  data  may  contain  any 
of  the  128  ASCII  character  codes.  The  mail  data  is  terminated  by  a  line 
containing  only  a  period,  that  is  the  character  sequence  •<CRIF>.<CRIF>*  (see 
paragraph  8.5.2  on  Transparency) .  This  is  the  end  of  mail  data  indication. 

The  end  of  mail  data  ndication  rtQuirts  that  the  receiver  must  now  process 
the  stored  mail  tranr*:tion  information.  This  processing  consumes  the  infor¬ 
mation  in  the  reverse-path  buffer,  the  forward-path  buffer,  and  the  mail  data 
buffer,  and  on  the  completion  of  this  command  these  buffers  are  cleared.  If 
the  processing  is  successful  the  receiver  must  send  an  OK  reply.  If  the 
processing  fails  completely  the  receiver  must  send  a  failure  reply.  When  the 
receiver-SNTP  accepts  a  message  either  for  relaying  or  for  final  delivery  it 
inserts  at  the  beginning  of  the  mail  data  a  timestamp  line.  The  timestamp 
line  indicates  the  identity  of  the  host  that  sent  the  message,  and  the  iden¬ 
tity  of  the  host  that  received  the  message  (and  is  inserting  this  timestamp), 
and  the  date  and  time  the  message  was  received.  Relayed  messages  will  have 
multiple  timestamp  lines.  When  the  receiver-SNTP  makes  the  “final  delivery* 
of  a  message  it  inserts  at  the  beginning  of  the  mail  data  a  return  path  line. 
The  return  path  line  preserves  the  information  in  tho  <reverse-path>  from  the 
NAIt  command.  Here,  final  delivery  means  the  message  leaves  tr  SNTP  world. 
Normally,  this  would  mean  it  has  been  delivered  to  the  destination  us*^r,  but 
in  some  cases  it  ma/  be  further  processed  and  transmitted  by  anotner  m%il 
system.  It  is  possible  for  the  mailbox  in  the  return  path  to  be  different 
from  the  actual  sender’s  mailbox;  for  example,  if  error  responses  are  to  be 
delivered  to  a  special  error  handling  mailbox  rather  than  to  the  message 
senders.  The  preceding  implies  that  the  finai  mail  data  will  begin  with  a 
return  path  tine,  followed  by  one  or  more  time  tamp  lines.  These  lines  will 
be  followed  by  the  mail  data  header  and  body.  e  paragraph  8. 

8, 1.1. 4.1  Response  and  fu.-ther  action.  Special  mention  is  needed  of  the 
response  and  further  action  required  when  the  processing  following  the  end  of 
mail  data  indication  is  partially  successful.  This  could  arise  if.  after 
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accepting  tevsral  reclplei.wS  an<J  the  m.*!l  <iSata,  the  recelver-SMTP  flnda  that 
the  mall  data  can  be  aucceaafully  dellv^ted  to  some  of  the  rtclplenta,  but 
It  cannot  be  to  othera  (for  example,  due  to  mailbox  apace  allocation  problema). 
In  auch  a  altuatlon.  the  reaponae  to  the  DATA  cor^nd  muac  t>e  an  OK  reply. 

But,  the  recelver-SMTP  Mi^.at  compoae  and  aend  an  "undell verac It  mail"  notifica¬ 
tion  meaaage  to  the  originator  of  the  meaaage.  Cither  a  aingle  notlflcatipn 
mhlch  liata  all  of  the  reclplenta  that  failed  to  get  the  meaaage.  or  aeparate 
notification  meaaagea  muat  be  aent  for  each  failed  recipient  (aee  paragraph 
7).  All  undeliverable  mall  notification  meaaagea  are  aent  ualng  the  MAIL 
command  (even  If  they  reault  from  proceaalng  a  SEND.  SOML,  or  SAML  command). 

6. 1,1. 4.2  Example  of  return  path  and  received  tlmeata^a. 

Return-f atK:  1  .AK^riblf  .aI>aTW  .Ak^A  ;16EBABC  . AIIPA> 

Received:  from  CMl.ARPA  by  JIQ..ARPA  ;  27  Oct  B1  15:27:39  PST 

Received:  from  DEP.ARPA  by  GHI.ARPA  ;  27  Oct  81  15:15:13  PST 

Received:  from  ABC. AR PA  by  DCF.ARPA  ;  27  Oct  81  15:01:59  PST 

Date:  27  Oct  81  15:01:01  PST 
From:  JOEfABC.ARPA 

Subject:  Improved  Hailing  Syatem  Inatalled 
To:  SAMfJKL.ARPA 

(Meaaage). 

6. 1.1.5  SEWD  (SEKD).  Thla  command  la  uaed  to  Initiate  a  amll  tranaactlon 
In  which  the  mall  data  la  delivered  to  one  or  more  terminala.  The  argument 
field  eontalna  a  reverae-path.  thla  coemand  la  aucccaaful  if  the  meaaage  la 
delivered  to  a  terminal.  The  reverae-path  conalata  of  an  optional  Uet  of 
hoati  and  the  aen.^er  mailbox.  Vhen  the  Hat  of  hoata  la  present,  it  la  a 
"reverat"  aource  route  and  Indlcatea  that  the  mall  waa  relayed  through  each 
boat  on  the  Hat  (the  flrat  hoat  In  the  Hat  waa  the  moat  recent  relay). 

Thla  Hat  la  uaed  aa  a  aource  route  to  return  non-delivery  notlcca  to  the 
aendcr.  Aa  each  reiay  hoat  adda  ItaelT  to  the  btfglnnlng  of  the  Hat.  it 
muat  uae  Ita  name  aa  known  in  the  XPCE  to  wnlrh  it  la  relaying  the  mall 
rather  than  the  IPCE  from  %#hlch  the  mall  came  (If  they  are  different).  Thla 
command  cleara  the  reverae-path  buffer,  the  forward-path  buffer,  and  the 
mall  data  buffer;  and  Inaerta  the  reverae*path  Information  from  thla  commend 
Into  the  reverae-path  buffer. 

8,1.;. 8  SEWD  or  H8IL  (SOML).  Thla  coemand  la  uaed  to  Initiate  a  mall 
tran  action  In  which  the  mail  data  la  delivered  to  one  or  more  temlnala  or 
mailboxes.  For  each  recipient  the  mall  data  la  delivered  to  Che  recipient *a 
terminal  If  the  recipient  la  active  on  the  hoat  (and  accepting  terminal 
meaaagea),  otherwlae  to  the  recipient's  mailbox.  The  argument  field  contains 
a  reverae-p«th.  Thla  command  is  successful  If  the  massage  la  delivered  to  a 
terminal  or  the  mailbox.  The  reveroe-path  consists  of  an  optional  Hat  of 
hoat«  er.d  the  sender  mailbox.  When  the  Hat  of  hoata  la  present.  It  la  a 
"reversit'  aource  route  and  Indlcatea  that  the  mall  waa  relayed  through  each 
host  on  the  Hat  (the  flrat  hoat  In  the  Hat  was  the  most  recent  relay). 

Thla  Hat  la  uaed  aa  a  source  route  to  return  non-delivery  notices  to  the 
sender.  At  esvh  relay  host  adds  itself  to  the  beginning  of  the  llet.  It 
must  uae  its  name  aa  W..rwn  In  the  XPCE  to  which  It  la  relaying  the  mall 
rathe*,  than  the  IPCE  from  which  the  mall  came  (If  they  are  different).  Thla 
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command  clears  the  reverse-path  buffer,  the  forward-path  buffer,  and  the 
mail  data  buffer;  and  Inserts  the  reverse-path  Information  from  this  command 
Into  the  reverse-path  buffer. 

6. 1.1.7  SEND  and  MAIL  (SAML).  This  command  Is  used  to  Initiate  a  mall 
transaction  In  which  the  mail  data  Is  delivered  to  one  or  more  terminals  and 
mailboxes.  For  each  recipient  the  mail  data  is  delivered  to  the  recipient’s 
terminal  if  the  recipient  Is  active  on  the  host  (and  accepting  terminal 
messages),  and  for  all  recipients  to  the  recipient’s  mailbox.  The  argument 
field  contains  a  reverse-path.  This  command  Is  successful  If  the  message  Is 
delivered  to  the  mailbox.  The  reverse-path  consists  of  an  optional  list  of 
hosts  and  the  sender  mailbox.  When  the  list  of  hosts  is  present,  It  Is  a 
"reverse"  source  route  and  Indicates  that  the  mall  was  relayed  through  each 
host  on  the  list  (the  first  host  In  the  list  was  the  most  recent  relay). 

This  list  Is  used  as  a  source  route  to  return  non-delivery  notices  to  the 
sender.  As  each  relay  host  adds  itself  to  the  beginning  of  the  list,  It 
must  use  its  name  as  known  In  the  IPCE  to  which  It  Is  relaying  the  mall 
rather  than  the  IPCE  from  which  the  mall  came  (If  they  are  different).  This 
command  clears  the  reverse-path  buffer,  the  forward-path  buffer,  and  the 
mall  data  buffer;  and  Inserts  the  reverse-path  Information  from  this  command 
Into  the  reverse-path  buffer. 

6. 1.1.8  RESET  (RSET).  This  command  specifies  that  the  current  mall  trans¬ 
action  Is  to  be  aborted.  Any  stored  sender,  recipients,  and  mall  data  must 
be  discarded,  and  all  buffers  and  state  tables  cleared.  The  receiver  must 
send  an  OK  reply. 

6. 1.1.9  VERIFY  (VRFY).  This  command  asks  the  receiver  to  confirm  that 
the  argument  identifies  a  user.  If  It  Is  a  user  name,  the  full  name  of  the 
user  (if  known)  and  the  fully  specified  mailbox  are  returned.  This  command 
has  no  effect  on  any  of  the  reverse-path  buffer,  the  forward-path  buffer,  or 
the  mall  data  buffer. 

6.1.1.10  EXPAND  (EXPN).  This  commai^  asks  the  receiver  to  confirm  that 
the  arguaenc  Identifies  a  mailing  list,  and  if  so,  to  return  the  membership 
of  that  list.  The  full  name  of  the  users  (If  known)  and  the  fully  specified 
mailboxes  are  returned  In  a  multiline  reply.  This  command  has  no  effect  on 
any  of  the  reverse-path  buffer,  the  forward-path  buffer,  or  the  mail  data 
buffer. 

6.1.1.U  HELP  (HELP).  This  command  causes  the  receiver  to  send  helpful 
information  to  the  sen<(er  of  the  HELP  comiaand.  The  command  may  take  an 
argument  (e.g.,  any  comsMind  name)  and  return  more  specific  Information  as  a 
response.  This  co«asnd  has  no  effect  on  eny  of  the  reverse-path  buffer,  the 
forward-path  buffer,  or  the  mall  data  buffer. 

6. K 1.12  HOOP  (HOOP).  This  command  does  not  affect  any  parameters  or 
prt'  lously  entered  cownds.  It  specifies  no  action  other  than  that  the 
receiver  send  an  OK  reply.  This  command  has  no  effect  on  any  of  the  reverse- 
path  buffer,  the  foniard-path  buffer,  or  the  mail  data  buffer. 


17 


M03 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


MlL-STD-1781 

10  May  1984 


6.1.1.13  (^IT  (QUIT).  This  command  specifies  that  the  receiver  must  send 
an  OK  reply,  and  then  close  the  transmission  channel.  The  receiver  should 
not  close  the  transmission  channel  until  it  receives  and  replies  to  a  QUIT 
command  (even  if  there  was  an  error).  The  sender  should  not  close  the  trans* 
mission  channel  until  it  send  a  QUIT  cotamand  and  receives  the  reply  (even  if 
there  was  an  error  response  to  a  previous  command).  If  the  connection  is 
closed  prematurely  the  receiver  should  act  as  if  a  RSET  command  had  been 
received  (canceling  any  pending  transaction,  but  not  undoing  any  previously 
completed  transaction),  the  sender  should  act  as  if  the  commaM  or  transaction 
in  progress  had  received  a  temporary  error  (4xx). 

6.1.1.14  TUIW  (TURN).  This  command  specifies  that  the  receiver  must 
either  (1)  send  an  OK  reply  ana  then  take  on  the  role  of  the  sender-SMTP ,  or 
(2)  send  a  refusal  reply  and  retain  the  role  of  the  rrcei^er-SNTP.  If 
program-A  is  currently  the  scniler-SMTP  and  it  sends  the  TURN  command  and 
receives  an  OK  reply  (250)  then  program-A  becomes  the  receive r-SMTP. 

Program-A  is  then  in  the  Initial  state  as  if  the  transmission  channel  just 
opened,  and  it  then  sends  the  220  service  ready  greeting.  If  program-B  is 
currently  the  receiver-SMTP  and  it  receives  the  TURN  command  and  sends  an  OR 
reply  (250)  then  program-B  becomes  the  sender-SMTP.  Program-B  is  then  in 
the  initial  state  as  if  the  transmission  channel  Just  opened,  and  it  then 
expects  to  receive  the  220  service  ready  greeting.  To  refuse  to  change 
roles  the  receiver  sends  the  502  reply. 

6.1.2  Restrictions.  There  are  restrictions  on  the  order  in  which  these 
commands  may  be  used.  The  first  command  in  a  session  must  be  the  HELD  command. 
The  HELO  command  may  be  used  later  in  a  session  as  well.  If  the  HELD  command 
argument  is  not  acceptable  a  501  failure  reply  must  be  returned  and  the 
receive r-SKTP  must  stay  in  the  some  state.  The  NOOP,  HELP,  EXPN,  and  VRPY 
commands  can  be  used  at  any  time  during  a  session.  The  HAIL,  SEND,  SOHL,  or 
SAHL  commands  begin  a  mail  transaction.  Once  started  a  mail  transaction 
consists  of  one  of  the  transaction  beginning  commands,  one  or  more  RCPT 
commands,  and  a  DATA  command,  in  that  order.  A  mail  transaction  may  be 
aborted  by  the  RSET  command.  There  may  be  aero  or  more  transactions  in  a 
session.  If  the  transaction  beginning  command  argument  is  not  acceptable  a 
501  failure  reply  must  be  returned  and  the  recelver-SKTP  muat  stay  in  the 

same  state.  If  the  commands  in  a  transaction  arc  out  of  order  a  503  failure 
reply  must  be  returned  and  the  receiver-SHTP  must  stay  in  the  aame  state. 

The  last  command  in  a  session  must  be  the  QUIT  command.  The  QUIT  command 
can  not  be  used  at  any  other  time  in  a  session. 

6.1.3  Comsmnd  syntax.  The  commands  consist  of  a  commsai  code  followed  by 
an  argument  field.  Command  codes  are  four  alphabetic  characters.  Upper  and 
lower  case  alphabetic  characters  are  to  be  treated  identically.  Thus,  any 
of  the  following  may  represent  the  mail  commend: 

NAIL  Hail  mail  Nall  bAII 

This  also  applies  to  any  sysbols  representing  parameter  values,  such  as  "TO* 
or  "to"  for  the  forward-path.  Command  codes  and  the  argument  fields  are  sepa¬ 
rated  by  one  or  more  spaces.  However,  within  the  reverse-path  and  forward- 
path  arguments  case  is  important.  In  particular.  In  some  hosts  the  user 
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"•■1th"  Is  dlffer«nt  from  the  user  ”S«lth**  The  srguaent  field  consists  ot  a 
vsrlsble  length  character  string  ending  with  the  character  sequence  <CRLF>. 
The  receiver  Is  to  take  no  action  until  this  sequence  Is  received*  Square 
brackets  denote  an  optional  argument  field.  If  the  option  Is  not  taken,  the 
appropriate  default  Is  loplled* 

6. 1.3.1  List  of  SMTP  cowsands.  The  following  are  the  SMTP  coj»ands: 

a.  HELO  <SP>  <doiialn>  <CRLP> 

b.  MAIL  <SP>  FROM:  <reverse-path>  <CRLP> 

c.  RCPT  <SP>  TO:<forward-path>  <CRLP> 

d.  D4T\  <CRLF> 

e.  RSST  <CRLF> 

f.  SEND  <SP>  FROM: <reverse-path>  <CRLF> 

g.  SOML  <SP>  FROM:<reverse-path>  <CRLF> 

h.  SAMl  <SP>  FROM: <reverse-path>  <CRLF> 

1,  VRFY  <SP>  <strlng>  <CRliF> 

j,  EXFN  <SP>  <strlng>  <CRLF> 

k,  HELP  [<SP>  <strlng>l  <CRLF> 

l,  NOOP  <CRLF> 

■•  QUIT  <CRLF> 

n.  TURN  <CRLF> 

6. 1.3.2  SMTP  syntax.  The  syntax  of  the  above  argument  fields  (using  BNF 
notation  where  applicable)  Is  given  below*  The  *..."  notation  indicates 
that  a  field  may  be  repeated  one  or  more  times. 

a*  <reverse“path>  <path> 

b.  <forward-path>  ::•  <path> 

c.  <path>  I  <a-d-l>  J  <mallbox>  •>" 

d.  <a-d-l>  <at-domaln>  |  <at-domaln>  ’,*  <a-d-l> 

e*  <at-dQmaln>  ::•  “f"  <domaln> 

f*  <domaln>  ::-  <slcment>  |  <eleMnt>  <domaln> 
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g.  <«ltMOt>  ::-  <iiaM>  |  <mi»b«r>  |  "["  <dotfiuB> 

h.  <Milboz>  <local*part>  <do«iln> 

1.  <local-part>  ::•  <dot*ttrlng>  |  <quotad-atrlnf> 

j.  <a«ae>  ; <«>  <ldh-ftr>  <l«t-dlg> 

k.  <ldh-itr>  <ltt-dlf-hyp>  |  <Ut-dlf-hyp>  <ldh-itr> 

l.  <let-dlg>  <a>  |  <d> 

m.  <Ut-dlf-hyp>  <«>  |  <d>  | 

n.  <dot*ttriqg>  <ttrlQf>  |  <«crlng>  **.“  <dot*striQg> 

0.  <tcring>  <char>  |  <diar>  <ttrlQf> 

p.  <quottd-atrlQi>  "**"  <qtaxt> 

q*  <qtaxt>  : \  <x>  |  \  <*>  <qttxt>  |  <q>  |  <q>  <qtaxt> 
r.  <char>  <c>  !  \  <*> 

a.  <dot^«>  <tnutt>  **•"  <tsiiia^  *.'*  <tiiu«>  <aBtt»> 

t.  <miiibtr>  <d>  |  <d>  <nuibar> 

u.  <CILr>  : J-  <CR>  <LF> 

V,  <CR>  :t-  tht  carriage  return  character  (A8CIX  code  13) 

V,  <lf>  the  line  feed  dharactar  (ASCII  code  10) 

X.  <SP>  the  apace  character  (ASCII  code  32) 

y.  <oiiuB>  one,  t«ie»  or  three  dlgita  repraaentlng  a  declaal 
integer  '^lue  in  the  range  0  through  233 

a.  <a>  : any  one  of  the  32  alphabetic  eharactera  A  through  Z 
in  upper  caae  and  a  through  i  in  loner  cate 

aa.  <c>  :i"  any  one  of  the  128  ASCII  eharactera,  but  not  any 
<apecial>  or  <8F> 

bb«  <d>  : any  one  of  the  ten  diglta  0  through  9 

cc.  <q>  any  one  of  the  128  ASCII  eharactera  except  <Cll>, 
<Lr>,  quote  (**),  or  baekalaah  (\) 

dd.  <x>  any  one  of  the  128  ASCII  eharactera  (no  exeeptiona) 
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€€•  <apeclal>  :: 


...  .<■  I  I  I  I  -p  I  »,»  I  -V  I 

1  1  **•**  I  “***  I  ’*®’*  **’*’*  I  control 

charactort  (ASCII  codas  0  through  31  Inclualva  and 
127) 


6. 1.3. 2.1  Spacial  nota.  Nota  that  tha  hackiiash,  is  a  quota  character, 

which  is  used  to  indicate  that  tha  next  character  is  to  be  used  Utarally 
(instead  of  its  normal  interpretation).  For  example,  “Joe, Smith"  could  be 
used  to  indicate  a  single  nine  character  user  field  with  cooma  being  the 
fourth  character  of  the  field.  Hosts  are  generally  known  by  naMs  which  are 
transUted  to  addresses  in  each  host.  Note  that  the  name  elements  of  domains 
are  the  official  names  no  use  of  nicknames  or  aliases  is  allowed.  Some» 
times  a  host  is  not  known  to  the  translation  function  and  communication  is 
blocked.  To  bypass  this  barrier  two  numeric  forms  are  also  allowed  for  host 
"names".  One  form  is  a  decimal  integer  prefixed  by  a  pound  sign,  which 

indicates  the  number  is  the  address  of  the  host.  Another  form  is  four  small 
decimal  integers  separated  by  dots  and  enclosed  by  brackets,  e.g., 
"1123.255.37.21",  which  indicates  a  32-blt  ARPA  Internet  Address  in  four 
8-bit  fields. 

6. 1.3. 3  Timestamp  end  return  path  lines.  The  timestamp  line  and  the 
return  path  line  are  formally  defined  as  follows: 

a.  <return-path-line>  "leturn-Path:"  <SPXreverse-path><CRLF> 

b.  <tlme-stamp-Une>  "Received:"  <SP>  <stamp>  <CRLF> 

c.  <stamp>  <from-domain>  <by-domaln>  <opt-lnfo> 

<daytime> 

d.  <frQm-domain>  "FROM"  <SP>  <domain>  <SP> 

e.  <by-domain>  "BY"  <SF>  <domia>  <SP> 

f.  <opt-info>  l<via>)  l<wlth>)  l<id>)  l<for>) 

g.  <vla>  "VU"  <SP>  <Unk>  <SP> 

h.  <with>  "WITH"  <SP>  <protocol>  <SP> 

i.  <id>  "10"  <SP>  <strini>  <SP> 

j.  <for>  "FOR"  <SP>  <path>  <SP> 

k.  <link>  : The  standard  names  for  links  are  registered  with 

the  Network  Information  Center. 

l.  <protocol>  : The  standard  names  for  protocols  are 

registered  with  the  Network  Information  Center. 

m.  <daytime>  <SP>  <dat«>  <SP>  <time> 
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n.  <date>  <dd>  <SP>  <mon>  <SP>  <yy> 

0.  <t1me>  <hh>  <inm>  <ss>  <SP>  <2one> 

p.  <dd>  the  one  or  two  decimal  integer  day  of  the  month  in 

the  range  1  to  31. 

q.  <mon>  "JAN*  1  "FEB**  1  “MAR*  !  "APR*  I  “MAY"  !  "JUN" 

"JUL*  1  *AU6*  !  “SEP"  !  "OCT*  !  “NOV*  ’  “DEC" 

r.  <yy>  the  two  decimal  integer  year  of  the  century  in  the 

range  00  to  99. 

s.  <hh>  the  two  decimal  integer  hour  of  the  day  in  the 

range  00  to  24. 

t.  <fflm>  the  two  decimal  integer  minute  of  the  hour  in  the 

range  00  to  59. 

u.  <ss>  the  two  decimal  integer  second  of  the  minute  in  the 

range  00  to  59. 

V.  <2one>  "UT*  for  Universal  Time  (the  default)  or  other 

time  zone  designator. 

8. 1.3. 3.1  Return  oath  example. 

Return -Path :  <9CHARL 1 E . ARPA .96AKER . ARPA : 30Ef ABLE . ARPA> 

6. 1.3. 3. 2  Timestamp  line  example. 

Received;  FROM  ABC. ARPA  BY  XYZ.ARPA  ;  22  OCT  B1  09:23:59  PDT 

Received:  from  ABC. ARPA  by  XYZ.ARPA  via  TELENET  with  X25 

id  M12345  for  Smith^POQ.ARPA  ;  22  OCT  81  09:23:59  POT 

^•2  SMTP  replies.  Replies  to  SMTP  commands  are  devised  to  ensure  the 
synchronization  of  requests  and  actions  in  the  process  of  mail  transfer,  and 
to  guarantee  that  the  sender-SMTP  always  knows  the  state  of  the  receiver-SMTP. 
Every  command  must  generate  exactly  one  reply.  The  details  of  the  command- 
reply  sequence  are  made  explicit  in  Section  5.3  on  Sequencing  and  Section  5.4 
State  Diagrams.  An  SNTP  '‘epiy  consists  of  a  three  digit  number  (transmitted 
as  three  alphanumeric  characters)  followed  by  some  text.  The  number  is 
intended  for  use  by  automata  to  determine  what  state  to  enter  next;  the  text 
is  meant  for  the  human  user.  It  is  intended  that  the  three  digits  contain 
enough  encoded  information  that  the  sender-SMTP  need  not  examine  the  text  and 
may  either  discard  it  or  pass  it  on  to  the  user,  as  appropriate.  In 
particular,  the  text  may  be  receiver-dependent  and  context  dependent,  so  there 
are  likely  to  be  varying  texts  for  each  reply  code.  A  discussion  of  the 
theory  of  reply  codes  is  given  in  paragraph  8.  Formally,  a  reply  is  defined 
to  be  the  sequence:  a  three-digit  code.  <SP>.  one  line  of  text,  and 
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<CRLF>,  or  a  multiline  reply  (as  defined  in  Appendix  E).  Only  the  EXPN  and 
HELP  commands  are  expected  to  result  in  multiline  replies  in  normal  circum¬ 
stances;  however,  multiline  replies  are  allowed  for  any  command. 

6.2.1  Reply  codes  by  function  groups. 

a.  500  Syntax  error,  conmand  unrecognized 

[This  may  include  errors  such  as  command  line  too  long] 

b.  501  Syntax  error  in  parameters  or  arguments 

c.  502  Command  not  implemented 

d.  503  Bad  sequence  of  commands 

e.  504  Coirmand  parameter  not  implemented 

f.  211  System  status,  or  system  help  reply 

g.  214  Help  message 

[Information  on  how  to  use  the  receiver  or  the  meaning  of  a 
particular  non-standard  command;  this  reply  is  useful  only  to 
the  human  user] 

h.  220  <domain>  Service  ready 

i.  221  <dofflain>  Service  closing  transmission  channel 

J.  421  <domain>  Service  not  available, 
closing  transmission  channel 

[This  may  be  a  reply  to  any  conmand  if  the  service  knows  it 
must  shut  down] 

k.  250  Requested  mail  action  okay,  completed 

l.  251  User  not  local;  will  forward  to  <forward-path> 

m.  450  Requested  mail  action  not  taken:  mailbox  unavailable 

[e.g.,  mailbox  busy] 

n.  550  Requested  action  not  taken;  mailbox  unavailable 

[e.g.,  mailbox  not  found,  no  access] 

0.  451  Requested  action  aborted;  error  in  processing 

p.  551  User  not  local;  please  try  < forward-path > 

q.  452  Requested  action  not  taken:  insufficient  system  storage 

r.  552  Requested  mail  action  aborted:  exceeded  storage  allocation 
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s.  553  Requested  action  not  taken;  mailbox  name  not  allowed 

[e.g.,  mailbox  syntax  incorrect] 

t.  354  Start  mail  input;  end  with  <CRLF>.<CRLF> 

u.  554  Transaction  failed 

6.2.2  Numeric  order  list  of  reply  codes. 

a.  211  System  status,  or  system  help  reply 

b.  214  Help  message 

[Information  on  how  to  use  the  receiver  or  the  meaning  of  a 
particular  non-standard  command;  this  reply  is  useful  only 
to  the  human  user] 

c.  220  <domain>  Service  ready 

d«  221  <domain>  Service  closing  transmission  channel 

e.  250  Requested  mail  action  okay,  completed 

f.  251  User  not  local;  will  forward  to  <forward-path> 

g.  354  Start  mail  input;  end  with  <CRlF>.<CRLF> 

h.  421  <domain>  Service  not  available, 

closing  transmission  channel 

[This  may  be  a  reply  to  any  command  if  the  service  knows  it 
must  shut  down] 

i.  450  Requested  mail  action  not  taken:  mailbox  unavailable 

[e.g.,  mailbox  busy] 

j.  451  Requested  action  aborted:  local  error  in  processing 

k.  452  Requested  action  not  taken:  insufficient  system  storage 

l.  500  Syntax  error,  command  unrecognized 

[This  may  include  errors  such  as  command  line  too  long] 

m.  501  Syntax  error  in  parameters  or  arguments 

n.  502  Connand  not  implemented 
0.  503  Bad  sequence  of  commands 

p.  504  Command  parameter  not  implemented 

q.  550  Requested  action  not  taken:  mailbox  unavailable 

[e.g.,  mailbox  not  found,  no  access] 
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r.  551  Umf  not  local;  pleaaa  try  <foniard*path> 

t.  552  Raquastad  aall  action  aborted:  axceedad  storage  allocation 

t«  553  Requested  action  not  taken:  aallbox  neat  not  allowed 
(E.g.,  aallbox  syntax  Incorrect] 

u*  554  Transaction  failed 

6.3  Sequencing  of  coMands  %nd  replies*  The  coaaunlcatlon  between  the 
sender  and  receipt  Is  Intended  to  m  an  alternating  dialogue,  controlled  by 
the  sender.  As  such,  the  sender  Issues  a  coaaand  and  the  receiver  responds 
with  a  reply.  The  sender  aust  wait  for  this  response  before  sending  further 
coaaands*  One  laportant  reply  Is  the  connection  greeting.  Noraally,  a 
receiver  will  send  a  220  "Service  ready”  reply  when  the  connection  Is  coa- 
pleted.  The  sender  should  wait  for  this  greeting  aessage  before  sending  any 
coaaands.  All  the  greeting  type  replies  have  the  official  naae  of  the  server 
host  as  the  first  word  following  the  reply  code.  For  exaaple, 

220  <SP>  USC*ISIP.ARPA  <SF>  Service  ready  <CRLP>.  Paragraph  6.3.1  lists 
alternative  success  and  failure  replies  for  each  coaaand.  These  aust  be 
strictly  adhered  to;  a  receiver  aay  substitute  text  In  the  replies,  but  the 
asanl:^  and  action  laplled  by  the  code  lu^rs  and  by  the  specific  coaaand 
reply  sequence  cannot  be  altered. 

6.3.1  Coeaand*reply  seqwnces.  Bach  coaaand  Is  listed  with  Its  possible 
replies.  tW  pte^l***  usm  Wlore  the  poeslble  replies  are  "F"  for  prellal* 
nary  (not  used  In  afTF),  *X*  for  Inteiaedlate,  "S"  for  success,  "P"  for 
failure,  and  "B*  for  error.  The  421  reply  (service  not  available,  closing 
transalsslon  channel)  aay  be  given  to  any  coaaand  If  the  SHTP’*recelver  knows 
It  aust  shut  down.  This  listing  foras  the  basis  for  the  State  Dlagraae  In 
paragraph  6.4. 

CONMEaiON  BSTABLISIMEMr 
St  220 
P:  421 
HELO 
S:  250 

E:  500,  501,  504.  421 
NAIL 
S:  250 

P:  552,  451,  452 
E:  500,  501,  421 

RCPT 

S:  250,  251 

P:  550,  551,  552,  553,  450,  451,  452 
E:  500,  501,  503,  421 
DATA 

I:  354  ->  data  ->  S:  250 

P:  552,  554,  451,  452 

P:  451,  554 
E:  500,  501,  503,  421 
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RSET 

S; 

E: 

SEND 

S: 

F: 

E: 

SGML 

S; 

F: 

E: 

S4ML 

S: 

F: 

E: 

VRFY 

S: 

F: 

E: 

EXPN 

S: 

F: 

E: 

HELP 

S: 

E: 

NOOP 

S: 

E: 

QUIT 

S: 

E: 

TURN 

S: 

F: 

E: 


250 

500.  501.  504.  421 
250 

552.  451.  452 
500.  501.  502.  421 

250 

552.  451.  452 
500.  501.  502.  421 

250 

552.  451.  452 
500.  501.  502.  421 

250.  251 

550.  551.  553 

500.  501.  502.  504.  421 

250 

550 

500.  501.  502.  504,  421 
211.  214 

500.  501.  502.  504.  421 
250 

500,  421 


250 

502 

500.  503 


State  dUgrams.  The  followInQ  are  state  (flayraMS  for  a  staple  SMTP 
lapleaenutton.  only  the  first  digit  of  the  reply  codes  Is  used.  There  Is 
one  state  diagran  for  each  group  of  SMTP  ccamands.  The  coaaand  groupings  we 
detemlned  by  constructing  a  aodel  for  each  coaaand  and  then  collecting 
together  the  coaaands  with  structurally  identical  aodels.  For  each  comnd 
there  are  three  possible  outcoaes:  "success*  (S),  ■failure*  (F),  and  *error 
(E).  In  the  state  diagraas  below  we  use  the  sy^l  B  for  "begin,*  and  the 
Sjaibol  M  for  *wa1t  for  reply.* 

S.4.1  SMTP  coaaands.  Figure  2  represents  aost  of  the  SMTP  comnds. 
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FtGUlS  2.  I>pr<H€nt«tion  of  moBt  of  thm  SKT?  copBandi# 
Plfurt  2  ■odcit  th«  cownnda: 

HELO,  MAIL,  RCPT,  WET,  SEMD,  80ML,  SAML,  WY,  EXPM,  HELP, 
NOOP,  QUIT,  TOW. 

6,4.2  Tht  PATA  corn^nd.  Flfura  3  m6mU  tht  DATA  eoMAod. 


— 1  DATA  I— 1 

71—— - W  ^  h" . . 


,.11. 

♦IwV 


FIOUU  3.  ThA  DATA  cowMiaH. 

NoCa  that  thA  *‘4AtA‘  Hafa  la  a  aarlaa  of  Uoaa  aaot  fro«  cha  aAoHAr  to  tho 
raealvAr  with  no  rAaponaa  Axpoctod  until  tho  laat  lino  la  aaot. 

6.5  PAtAlla. 

6.5.1  iAolAAAtttatiot>.  In  ordor  to  sakA  SNTP  wodLabla,  tha  folloir- 

Ing  miolauB  laplAA^tatlon  la  :.AqttlrAd  for  all  racAlvarat 
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COMMANDS  —  HELO 
MAIL 
RCPT 
DATA 
RSET 
HOOP 
QUIT 

ocy*  Without  toM  provision  for  dots  trsnspsrsncy  tht 
chsrscttr  isquones  ‘*<CRLr>.<CRLP>"  snds  ths  Mil  ttxt  and  cannot  bo  sont 
by  tht  ustr.  In  ftntrtl»  ustrt  art  not  auart  of  ouch  "forblddtn**  saquonets. 

To  allow  all  ustr  eoipos^i  ttxt  to  bt  transaltttd  transpartntly  tht  followlnf 
proctdurts  art  ustd. 

a.  Btfort  sanding  a  lint  of  Mil  ttxt  tht  stadtr-SMTP  chocks  tht 
first  characttr  of  tht  lint.  If  It  Is  a  ptrlod,  ont  additional 
ptrlod  is  Instrttd  at  tht  btflnnlng  of  tht  lint. 

b.  Whan  a  lint  of  Mil  ttxt  Is  rtctlvtd  by  tht  rtctlvtrHSMTP  it 
ehteks  tht  lint.  If  tht  lint  Is  cospostd  of  a  slnflt  ptrlod  It 
Is  tht  and  of  Mil.  If  tht  first  characttr  Is  a  ptrlod  and 
thtrt  art  othtr  charaettrs  on  tht  lint,  tht  first  characttr  Is 
dtltttd. 

^•5*2.1  ASCII  charaettrs.  Tht  mU  data  My  contain  any  of  tht  128  ASCII 
charaettrs. All  charaettrs  art  to  bt  dtllvtrtd  to  tht  rtelpltnt's  Mllbox 
Including  forMt  tfftetors  and  othtr  control  charaettrs.  If  tht  traniMlsslon 
channtl  provldts  an  8*blt  bytt  (octtts)  data  strtM.  tht  7«*blt  ASCII  codas 
art  transnltttd  right  justlfltd  In  tht  octtts  with  tht  high  ordtr  bits  cltartd 
to  stro.  In  SOM  systtM  It  My  bt  ntetssary  to  transfom  tht  data  aa  It  Is 
rtctlvtd  and  stortd.  This  My  bt  ntetssary  for  hosts  that  ust  a  dlfftrtnt 
characttr  sat  than  ASCII  as  thtlr  local  characttr  Mt.  or  that  stort  data  In 
rtcords  rathar  than  strings.  If  such  transforM  art  ntetssary.  thty  wuat  bt 
rtvtrslblt  —  tsptelally  if  such  transfoiM  art  applltd  to  Mil  btlng  rtlaytd. 

Py*  stvtral  objtets  that  havt  rtqulrtd  nlnlnun  mxImb 
sltts.  That  Is.  ovary  lapltMntatlon  Bust  bt  ablt  to  rtctlvt  objtets  of  at 
Itast  thtsa  slsts.  but  Bust  not  sand  objtets  larger  than  thtst  sltts.  To  tht 
MxlBUB  txtant  posslblt.  InpltBontatlon  ttchnlquts  which  iBpost  no  llBlts  on 
tht  Itngth  of  thtst  objtets  should  bt  ustd. 

a.  Ustr 

Tht  MxlMB  total  Itngth  of  a  ustr  naM  Is  84  charaettrs. 

b.  DoMln 

Tht  MxlBUB  total  Itngth  of  a  doMln  mm  or  nuabtr  Is  84 
charaettrs. 

c.  Path 

Tht  MxlBUB  total  Itngth  of  a  rtvtrot*path  or  ferward*path  It 
258  charaettrs  (Including  tht  punctuation  and  oltMot  stparators). 
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4. 


COHMOd  LIm 

Th«  total  lottfth  of  a  eoiBaiid  Una  laeludlnf  tha  eoMUful 

word  and  tha  <aiLr>  la  S12  eharactara. 


a* 


Tha  total  langth  of  a  raplj  Una  Inelodlni  tha  raplj 

coda  and  tha  <CtLr>  la  S12  eharaetara. 


f  Tast  Lina 

Tha  total  langth  of  a  ta*t  Una  Including  tha  <CtLF>  la 

1000  charactara  (hut  not  counting  tha  landing  dot  dupllcatad 
for  tcanaparancy)* 


I* 


ftaclylanta  Buffar 

tha  naxlauti  total  mutSbot  of  raclylanta 
100  raclylanta. 


that  auat  ha  buffarad  la 


6,5.?. 1  Irror  Tanly  codaa*  Ittora  dua  to  axcaadlng  thaaa  Unlta  nay  ha 
raportac  hy  ualng  tna  rapfjT^codaa,  for  ana^la: 


500  Lina  too  long* 

501  Path  too  long* 

552  T^  nany  raclplanta* 
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7.  SERVICES 

7.1  Transmission  Control Protocol  (TCP)  transport  service*  The  Transmission 
Control  Protocol  (Mii-STiJ-  i/zb;  is  mandatory  for  use  in  all  OoO  packet 
switched  networks  which  connect  or  have  the  potential  for  utlllzinp 
connectivity  across  network  or  subnetwork  boundaries. 

7.1.1  Connection  establishment.  The  SMTP  transmission  channel  Is  a  TCP 
connection  established  between  £Rc  sender  process  port  U  and  the  receiver 
process  port  L.  This  single  full  duplex  connection  Is  used  as  the  transmis* 
Sion  channel.  This  protocol  Is  assigned  the  service  port  25  (31  octal),  that 
Is  L  •  25. 

7*1.2  Data  transfer.  The  TCP  connection  supports  the  transmission  of  8*b1t 
bytes.  The  SMtP  data  Is  7-b1t  ASCII  characters.  Each  character  Is 
transmitted  as  an  8-b1t  byte  with  the  high-order  bit  cleared  to  zero. 

7.2  X.25  transport  service.  It  may  be  possible  to  use  the  X,25  service  as 
directly  provided  by  the  Public  Data  Networks.  However,  It  Is  suggested  that 
a  reMable  end-to-end  protocol  such  as  TCP  be  used  on  top  of  X.25  connections. 
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S:  RSET 
Rj  250  OK 

S:  QUIT 

R:  221  MIT-Multics*ARPA  Service  cloeing  trensalsslon  channel 
9.4  Relayed  mall  scenario. 

9.4.1  Source  host  to  relay  host, 

R:  220  USC-ISXE,ARPA  Slaple  Mall  Transfer  Service  Ready 
S:  HELO  MIT-AI.ARPA 
R:  250  USC-ISIE.ARPA 

S:  MAIL  FR0M:<JQP®1IT-AI.ARPA> 

R:  250  OR 

S:  RCPT  TO:<8USC-ISIE.ARPA:Jonea9BBN-VAXjaiPA> 

R:  250  OR 

S:  DATA 

R:  354  Start  sail  Input;  end  with  <CiaF>.<CRLF> 

S:  Date:  2  Nov  81  22:33:44 

5:  Fron:  John  Q.  Public  <JQP8MIT-AI.ARPA> 

S:  Subject:  The  Next  Meeting  of  the  Board 
S:  To:  Jones WN-Vax.ARPA 
S: 

S:  Bill: 

S:  The  next  aeetlng  of  the  board  of  directors  will  ba 
S:  on  Tuesday. 

S:  John. 

S:  . 

R:  25)  OK 
S:  QUIT 

R:  221  USC-ISIE.ARPA  Service  closing  transmission  channel 

9.4.2  Relay  host  to  destination  host. 

R:  220  BBN-VAX.ARPA  Sloiple  Nall  Transfer  Service  Ready 
S:  Hao  USC-ISIE.ARPA 
R:  250  BBN-VAX.ARPA 

S:  NAIL  FROM:<8USC-XSXE.ARPA:JQPfHlT-AI.ARPA> 

R:  250  OX 


S:  RCPT  TO: <JonesfBBN-VAX.ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  met  I  In^ut;  end  vlth  <CRLF>.<CRLF> 
S:  Received:  from  HIT-Al.ARPA  by  USC-ISIE.ARPA  ; 
2  Nov  81  22:40:10  UT 
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9.  SCENARIOS 


9.1  Introduction.  This  section  presents  complete  scenarios  of  several 
types  of  SMTP  sessions. 


9.2  A  typical  SMTP  transaction  scenario.  This  SMTP  example  shows  mall  sent 


by  Smith  at  host  USC-ISIF,  to  Jones.  Green,  and  Brown  at  host  BBN-UNIX.  Here 
we  assume  that  host  USC-ISIF  contacts  host  BBN-UNIX  directly.  The  mail  Is 
accepted  for  Jones  and  Brown.  Green  does  not  have  a  mailbox  at  host  BBN-UNIX 


R;  220  EBN-UNIX.ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  USC-ISIF.ARPA 
R:  250  BBN-UNIX. ARPA 


S:  MAIL  FR0M:<Sffl1th8USC-ISIF.ARPA> 
R:  250  OX 


S:  RCPT  T0:<Jones9BBN-UNIX.ARPA> 
R:  250  OK 


S:  RCPT  T0:<Green8BBN-UNIX.ARPA> 
R:  550  No  such  user  here 


S:  RCPT  TO:<BrownfBBN-UNIX.ARPA> 
R:  250  OK 


S:  DATA 

R:  354  Start  mall  input;  end  with  <CRIF>.<CRLF> 
S:  ...etc.  etc.  etc. 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 


S;  QUIT 

R:  221  BBN-UNIX. ARPA  Service  closing  transmission  channel 


R:  220  MIT-MuUlcs.ARPA  Simple  Mall  Transfer  Service  Ready 
S:  HELO  ISI-VAXA.ARPA 
R:  250  MlT-MuUICS.ARPA 


S:  MAIL  FR0M:<Sm1th«I$I-VAXA.ARPA> 
R:  250  OK 


S:  RCPT  T0:<Jones|MIT-MuU1cs.ARPA> 
R:  250  OK 


$:  RCPT  T0:<6reen#MiT-MuU1cs.ARPA> 
R:  550  Nc  such  user  here 
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8.1.2  Values  for  the  second  digit.  The  second  digit  encodes  responses  in 
specific  categories: 

8. 1.2. 1  Syntax  (xOz).  These  replies  refer  to  syntax  errors,  syntactically 
correct  commands  that  don't  fit  any  functional  category,  and  unimplemented 

or  superfluous  commands. 

8. 1.2.2  Information  (xlz).  These  are  replies  to  requests  for  information, 
such  as  status  or  help. 

8« 1*2.3  Connections  (x2g).  These  are  replies  referring  to  the  transmission 
channel . 

8. 1.2.4  Unspecified  (x3g). 

8.1.2. 5  Unspecified  (x4x). 

8. 1.2.6  Mail  system  (x5z).  These  replies  Indicate  the  status  of  the 
receiver  mail  system  vis-a-vis  the  requested  transfer  or  other  mail  system 
action. 


8*1*3  Values  for  the  third  digit.  The  third  digit  gives  a  finer  gradation 
of  meaning  in  each  category  specified  by  the  second  digit.  The  list  of 
replies  illustrates  this.  Each  reply  text  is  recommended  rather  than  manda¬ 
tory,  and  may  even  change  according  to  the  command  with  which  it  is  associated. 
On  the  other  hand,  the  reply  codes  must  strictly  follow  the  specifications 
in  this  section.  Receiver  implementations  should  not  invent  new  codes  for 
slightly  different  situations  from  the  ones  described  here,  but  rather  adapt 
codes  already  defined.  For  example,  a  command  such  as  NOOP  whose  successful 
execution  does  not  offer  the  sender-SMTP  any  new  information  will  return  a 
250  reply.  The  response  is  502  when  the  command  requests  an  unimplemented 
non-slte-speciflc  action.  A  refinement  of  that  is  the  504  reply  for  a  command 
that  is  implemented,  but  that  requests  an  unimplemented  parameter. 

8*i*3.1  Special  format.  The  reply  text  may  be  longer  than  a  single  Une; 
in  these  cases  the  complete  text  must  be  marked  so  the  sender-SMTP  knows 
when  it  can  stop  reading  the  reply.  This  requires  a  special  format  to  indi¬ 
cate  a  multiple  line  reply.  The  format  for  oRiItiline  replies  requires  that 
every  line,  except  the  last,  begin  with  the  reply  code,  followed  ImiMdiately 
by  a  hyphen,  **-•*  (also  known  as  minus),  followed  by  text.  The  last  line 
will  begin  with  the  reply  code,  followed  immediately  by  <SP>,  optionally 
some  text,  and  <CRLF>.  For  exaa«>le: 

123  -  First  line 
123  -  Second  line 

123-234  Text  beginning  with  numbers 
123  -  The  last  line 

In  many  cases  the  sender-SMTP  then  simply  needs  to  search  for  the  reply  code 
followed  by  <SP>  at  the  beginning  of  a  line,  and  ignore  all  preceding  lines. 

In  a  few  cases,  there  is  Important  data  for  the  sender  in  the  reply  "text." 

The  sender  will  know  these  canes  from  the  current  context. 
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8.  THEORY  OF  REPLY  CODES 

8*1  Introduction*  The  three  digits  of  the  reply  e*ich  have  a  special 
significance.  The  first  digit  denotes  whether  the  response  is  good,  bad  or 
incoBplete.  An  unsophisticated  sender-SMTP  will  be  able  to  determine  its 
next  action  (proceed  as  planned,  redo,  retrench,  etc.)  by  simply  examining 
this  first  digit.  A  sender-SMTP  that  wants  to  know  approximately  what  kind 
of  error  occurred  (e.g. ,  mail  system  error,  command  syntax  error)  may  examine 
the  second  digit,  reserving  the  third  digit  for  the  finest  gradation  of 
information. 

8.1.1  Values  for  the  first  digit.  There  are  five  values  for  the  first 
digit  of  the  reply  code. 

8.1.1.1  Positive  preliminary  reply  (lys).  The  command  has  been  accepted, 
but  the  requested  action  is  being  held  in  abeyance,  pending  confirmation  of 
the  information  in  this  reply,  the  sender-SMTP  should  send  another  command 
specifying  whether  to  continue  or  abort  the  action.  SMTP  does  not  have  any 
commands  that  allow  this  type  of  reply,  and  so  does  not  have  the  continue  or 
abort  commands. 

8. 1.1.2  Positive  c<wletion  reply  (2ya).  The  requested  action  has  been 
successfully  completed.  A  new  request  may  be  Initiated. 

8. 1.1.3  Positive  intermediate  reply  (3ya)*  the  command  has  been  accepted, 
but  the  requested  action  is  being  held  in  abeyance,  pending  receipt  of  further 
information.  The  sender'^SMTP  should  send  another  curaand  pacifying  this 
information.  This  reply  is  used  in  command  sequence  groups. 

8. 1.1.4  Transient  negative  completion  reply  (4ya).  The  command  was  not 
accepted  andi  the  requested  action  did  not  occur.  However,  the  error  condition 
is  temporary  and  the  action  may  be  requested  again*  The  sender  should  return 
to  the  beginning  of  the  command  sequence  (if  any).  It  is  difficult  to  assign 
a  meaning  to  "transient**  when  two  different  sites  (receiver**  and  sender* 

SMTPs)  must  agree  on  the  interpretation.  Each  reply  in  this  category  might 
have  a  different  time  velue,  but  the  sender*SKTF  is  encouraged  to  try  again. 

A  rule  of  thumb  to  detetmine  if  a  reply  fits  into  the  4ys  or  the  Sys  category 
(see  below)  is  that  replies  are  4ys  if  they  can  be  repeated  without  any 
change  in  command  form  or  in  properties  of  the  sender  or  receiver.  (E.g., 
the  command  is  repeated  identically  and  the  receiver  does  not  put  up  a  new 
implementation.) 

8.1. 1.5  Permanent  negative  completion  reply  The  command  wa.^  not 

accepted  and  the  requested  action  did  not  occur,  the  sends r*SHTP  is  discour¬ 
aged  from  repeating  the  exact  request  (in  the  same  sequence).  Even  some 

** permanent**  error  conditions  can  be  corrected,  so  the  human  user  may  want  to 
direct  the  sender-ShTP  to  reinitiate  the  command  sequence  by  direct  action 
St  some  point  in  the  future  (e.g.,  after  the  spelling  has  been  changed,  or 
the  user  has  altered  tho  account  status). 
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S:  Date:  2  Nov  81  22:33:44 

S:  From:  John  Q.  Public  <JQP8NIT>AI.ARPA> 

S:  Subject:  The  Next  Meeting  of  the  Board 
S:  To:  JonesBBBN-Vax.ARPA 
S: 

S:  8111: 

S:  The  next  meeting  of  the  board  of  directors  will  be 
S:  on  Tuesday. 

S:  John. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  USC-ISIE.ARPA  Service  closing  transmission  channel 

9.5  Verifying  and  sending  scenario. 

R:  220  SU-SCORC.ARPA  Simple  Nall  Transfer  Service  Ready 
S:  HELO  NIT'NC.ARPA 
R:  250  SU-SCORE.ARPA 

S:  VRFY  Crispin 

R:  250  Nark  Crispin  <Adm1n.NRC8SU*SC0RE.ARPA> 

S:  SEND  FR0N:<EAK8N1T>NC.ARPA> 

R:  250  OK 

S:  RCPT  T0:<Adm1n.NRCfSU-SC0RE.ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mall  Input;  end  with  <CRIF>.<CRLF> 

S:  ...etc.  etc.  etc. 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  SU-SCORE.ARPA  Service  closing  transmission  channel 

9.8  Sending  and  mailing  scenarios.  First  the  user’s  name  Is  verified,  then 
an  attempt  Is  made  to  send  to  the  user’s  terminal.  When  that  falls,  the 
message  Is  mailed  to  the  user's  mailbox. 

R:  220  SU-SCORE.ARPA  Simple  Nall  Transfer  Service  Ready 
S:  HEIO  NI7-NC.ARPA 
R:  250  SU-SCORE.ARPA 

S:  VRFY  Crispin 

R.  250  Nark  Crispin  <Adm1n.NRCfSU-SC0RE.ARPA> 

S:  SEND  FR0N:<EAK|N1T-NC.ARPA> 

R:  250  OK 
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S:  RCPT  T0:<A(lffl1n.NRC8SU-SC0R£.ARPA> 

R:  450  User  not  active  now 

S:  RSET 
R:  250  OK 

S:  HAIL  FR0M:<EAK#NIT-HC.ARPA> 

R:  250  OK 

S:  RCPT  T0:<Adm1n.MRC#SU-SC0RE.ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mail  Input;  end  with  <CRLF>.<CRLF> 

S:  ...etc.  etc.  etc. 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  SU-SCORE.ARPA  Service  closino  transmission  channel 


R:  220  SU-SCORE.ARPA  Simple  Hall  Transfer  Service  Ready 
S:  HELO  HIT-HC.ARPA 
R:  250  SU-SCORE.ARPA 

S:  VRFY  Crispin 

R:  250  Hark  Crispin  <Adm1n.HRCfSU-SC0RE.ARPA> 


S:  SOHL  FRQH:<EAKfHIT-HC.ARPA> 

R:  250  OK 

S:  RCPT  T0:<Adm1n.HRCfSU-SC0RE.ARPA> 

R:  250  User  not  active  now.  so  will  do  mall. 

Si  DATA 

R:  354  Start  mall  Input;  end  with  <CRIF>.<CRLF> 

S:  ...etc.  etc.  etc. 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R;  221  SU-SCORE.ARPA  Service  closing  transmission  channel 

9.7  Halllna  list  scenario.  First  each  of  two  mailing  lists  are  expanded  In 
separate  sessions  with  different  hosts.  Then  the  message  Is  sent  to  everyone 
that  appeared  on  either  list  (hut  no  duplicates)  via  a  relay  host. 
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9.7.1  Expanding  th€  flrit  list* 

R;  220  MITHII.ARPA  Slaple  Mall  Transfer  Service  Ready 
S:  HELO  SU-SC0RE.ARPA 
R:  250  MIT-AI.ARPA 


8: 

R: 

R: 

R: 

R: 

R: 

R: 


BXPN  Exan)le-People 

250-<ABC^IT-HC.ARPA> 

250-Fred  Fonebone  <Fonebone8USC-ISIQ.ARPA> 

250-Xenon  Y.  Zither  <XYZ?M1T-AI.ARPA>  aopa-v 

250-<Julncy  Smith  <gUSC-ISIF.ARPA:Q-Smlth«ISI-VAW.ARPA> 
2 50-<J  oe§f  oo-unlx .  ARPA> 

250  <xya§bar-unlx.ARPA> 


S: 

R: 


221  MIT-AI.ARPA  Service  closing  transalsslon  channel 


9.7.2  Expanding  the  second  list. 

Ri  220  MT-MC-ARPA  Simple  Hell  Trenefer  Service  Reedy 
S:  HELO  SU-8C0RE.ARPA 
R;  250  MIT-MC.ARPA 


S: 

R: 

R: 

R: 

Rt 

R: 


EXFll  Interested-Parties 

250-Al  Calico  <ABC»!IT-«C.AR?A> 

250-<Xn#MIT-Al.ARPA> 

250-Qulncy  Snlth  <fUSC-ISIF.ARPA: 

250-<fred|BBll-UMIX.ARPA> 

250  <xyaibarmnlx.ARPA> 


Q-S«lth9ISI-VAXA.ARPA> 


R;  221  MIT-MC.ARPA  Service  closing  transnlsslon  channel 

9.7.3  Mailing  to  all  via  a  relay  host. 

R!  220  08C-1SIE.ARPA  Sl^le  Mall  Transfer  Service  Ready 
8:  HELO  SU-SC0RE.ARPA 
r:  250  USC-ISIB.ARPA 

S:  NAIL  FR0M:<Account.PersonfSU-SC0RE.ARPA> 

R:  250  OR 

S;  RCPT  TOi<|USC-ISIB.ARPA:ABC^IT-MC.ARPA> 

R*  250  OR 

S:  RCPT^TO: <fUSC-ISIB.ARPA5FooebonefU5C-ISIQA.ARPA> 

R:  250  OR 

S:  RCrr  T0:<9USC-ISIE.ARPAsmHHIT-AI.ARPA> 

R:  250  OR 
S •  RCFT 

TOl  <9USC-IS1E.ARPA,C0SC-ISIF.ARPA;  Q-S«lthiISI-VAXA.ARPA> 

Re  250  OR 

$:  RCFT  TO:<fUSC-ISIBJUlPA;ioefFOO-UNIX.ARFA> 

R:  250  OR 

si  RCPT  TO:<tO8C-lSIB.AtPA!xyaiBAR-0NIX.ARPA> 
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R:  250  OK 

S:  RCPl  TO:<fUSC-ISIE.ARPA:frtdWBN-UNIX.ARPA> 
R:  250  OK 


R:  354  Start  mall  Input;  end  with  <CRLF>.<CRLF> 

S:  ...etc.  etc.  etc. 

S:  ...etc.  etc.  etc. 

S:  . 

R;  250  OK 
S:  QUn 

R:  221  USC-ISIE.ARPA  Service  closing  transmission  channel 


R:  220  USC’ISIF.ARPA  Simple  Mall  Transfer  Service  Ready 
S:  HELD  LBL-UNU.ARPA 
R:  250  USC-ISIF.ARPA 

S:  MAIL  FROM:<mofLBl-UMlX.ARPA> 

R:  250  OK 

S:  RCPT  TO:<fredfUSC-lSIF.ARPA> 

R:  251  User  not  local;  will  forward  to  <JonesfUSC-ISI.ARPA> 
S:  DATA 

R:  354  Start  mall  Input;  end  with  <CRLF>.<CRLF> 

S:  ...etc.  etc.  etc. 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  USC-ISIF.ARPA  Service  closing  transmission  channel 


R:  220  USC-ISIF ,ARPA  Simple  Mall  Transfer  Service  Ready 
S;  HEIO  IBL-UNIX.ARPA 
R;  250  USC-ISIF.ARPA 

S:  MAIL  FROM:<mo#LBL-UNlX.ARPA> 

R:  250  OK 

S:  RCPl  TO:<fred#USC-ISlF.ARPA> 

R;  251  User  not  local;  will  forward  to  <Jones#USC-ISI.ARPA> 


S:  RSEl 
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R:  221  USC-ISIF.ARPA  Service  closing  transulsslon  channel 

9.9.2  Delivering  the  isall  at  the  second  host* 

R:  220  USC-ISI.ARPA  Simple  Hall  Transfer  Service  Ready 
S:  HELO  L8L-UNIX.ARPA 
R:  250  USC-ISI.ARPA 

S:  HAIL  FR(m:<liK)fL8L-UNIX.ARPA> 

R:  250  OK 

S:  RCPT  TO:<Jones#USC-ISI.ARPA> 

R:  OK 

S:  DATA 

R:  354  Start  mall  Input;  end  with  <CRLF>.<CRLF> 

S:  ...etc.  etc.  etc. 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  USC-ISI.ARPA  Service  closing  transmission  channel 

9.10  Toe  many  recipients  scenario. 

R;  220  8ERKELEY.ARPA  Simple  Hall  Transfer  Service  Ready 
S:  HELO  USC-ISIF.ARPA 
R:  250  BERKELEY. ARPA 

S:  HAIL  FROH:<Postel#USC-ISIF.ARPA> 

R:  250  OK 


kv 


RCPT  TO:<fabry#BERKELEY.ARPA> 
250  OK 


RCPT  T0:<er1c#BERKELEY.ARPA> 

552  Recipient  storage  full,  try  again  In  another  transaction 


S 

R 

S 

S 

S 

R 


DATA 


354  Start  mall  Input;  end  with  <C8LF>.<CRLF> 
...etc.  etc.  etc. 

...etc.  etc.  etc. 


2S0  OK 


m 


MAIL  FftOM:<Post,i9USC-ISlF.ARPA> 
ZSO  OK 


RCPT  T0:<er1c#BERKELEY.ARPA> 
250  OK 


v'lv' 
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S:  DATA 

R:  354  Start  mall  input;  end  with  <CRLF>,<CRLF> 

S:  ...etc.  etc.  etc. 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  BERKELEY. ARPA  Service  closing  transmission  channel 

Note  that  a  real  implementation  must  handle  many  recipients  as 
specified  in  Section  4.5.3. 
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1.  This  Military  Standard  Is  approved  for  use  by  all  Departments  and 
Agencies  of  the  Department  of  Defense. 

2.  Beneficial  comments  (recoomendatlons,  additions,  deletions)  and  any 
pertinent  data  which  may  be  of  use  In  Improving  this  document  should  be 
addressed  to:  Defense  Communications  Agency.  ATTN:  J110,  1860  Wiehle  /Wenue. 
Reston,  Virginia  22090.  by  using  the  self-addressed  Standardization  Document 
Improvement  Proposal  (DD  Form  1426)  appearing  at  the  end  of  this  document,  or 
by  letter. 

3.  Because  of  the  rapid  development  In  this  standardization  area,  an 
alternative  method  of  comaunl cation  Is  offered.  Forward  responses  using  the 
MILNET  to  DCA-IAS  0  DCA-pIS.  Cooperation  of  the  user  Is  Important  to  make 
this  protocol  meet  beparfiSht  of  Defense  needs. 
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FOREWORD 

This  docu^ant  tpacifltt  the  TELNET  protocol  and  a  nuwber  of  approved  optiona. 
It  provides  a  standard  iiethod  of  Interfacing  temlnal  devices  and  terminal- 
oriented  processes  to  each  other*  It  Is  envisioned  that  the  protocol  may  also 
be  used  for  tentinal-temlnal  conunication  ("linking**)  and  process-process 
communication  (distributed  computation)* 
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1 ,  SCOPE 

1.1  Purpose.  This  standard  establishes  criteria  for  the  TELNET  Protocol 
which  supports  the  standard  method  of  Interfacing  terminal  devices  and 
terminal -oriented  processes  to  each  other. 

1.2  Oraanizatlon.  This  standard  Introduces  the  TELNET  P»*otocols  role»  ^ 
defines  tne  services  provided  to  users,  and  specifies  the  mechanisms  needed  to 
support  those  services.  This  standard  also  Includes  an  appendix  of  options 
which  can  be  Implemented  In  the  TELNET  Protocol  and  a  glossary  of  terms  and 
abbreviations. 

1.3  ADDllcatlon.  This  TELNET  Protocol  Is  approved  for  use 

njcket  pitching  networks  which  connect  or  have  the  potential  for  utilizing 
connectivity  across  network  and  subnetwork  boundaries  and  which  require  a 
virtual  terminal  service.  The  term  network  as  used  herein  Includes  Local  Area 

Networks. 
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2.  REFERENCED  DOCUMENTS 

2.1  Issues  of  documents.  The  following  documents  of  the  issue  in  effect  on 
date  of  invitation  for  bids  or  request  for  proposal,  form  a  part  of  this 
standard  to  the  extent  specified  herein. 

STANDARDS 

FEDERAL 

FED-STD-1037  Glossary  of  Telecommunications  Terms 

MILITARY 

MIL-STO-1778  Transmission  Control  Protocol 

2.2  Other  publications*  The  following  documents  form  a  part  of  this 
standara  to  the  extent  specified  herein.  Unless  otherwise  indicated,  the 
issue  in  effect  on  date  of  invitation  for  bids  or  request  for  proposal  shall 
apply.  (The  provisions  of  this  paragraph  are  under  consideration.) 
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3.  DEFINITIONS 

3.1  Definition  of  terms.  The  definition  of  terms  used  in  this  standard 
shall  comply  with  l=’Ed-SirD-1037.  Terms  and  definitions  unique  to  MIL-STD-1782 
are  contained  herein.  (The  provisions  of  this  paragraph  are  under 
consideration.) 

3.2  Definitions  of  acronyms  used  in  this  standard.  The  following  acronyms 
used  in  this  Military  Standard  are  defined  as  follows: 


a. 

AD 

Abort  Output  Command 

b. 

AYT 

Are  You  There  Command 

c. 

6S 

- 

Back  Space 

d. 

CR 

- 

Carriage  Return 

e. 

DON 

- 

Defense  Data  Network 

f. 

DM 

Data  Mark 

9- 

DoO 

- 

Department  of  Defense 

h. 

OODIIS 

- 

DoD  Intelligence  Information  System 

1. 

EC 

Erase  Character  Command 

J. 

EL 

Erase  Line  Command 

k. 

FF 

- 

Form  Teed 

1. 

6A 

• 

Go-.Ahead  Command 

m. 

. 

Horizontal  Tab 

n. 

lAC 

- 

Interpret  As  Command 

0. 

I8M 

International  Business  Machines,  Inc. 

p. 

IP 

• 

Interrupt  Process  Command 

9* 

LF 

• 

Line  Feed 

r. 

NVT 

• 

Network  Virtual  Terminal 

s. 

TCP 

• 

Transmission  Control  Protocol 

t. 

TELNET 

Telecommunications  Network 

u. 

VT 

. 

Vertical  Tab 

V. 

ASCII 

- 

American  Standard  Code  for  Information  Interchange 

. » •  ^ 
■  V  A 
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4.  GENERAL  REQUIREMENTS 

4.1  Introduction.  The  purpose  of  the  TELNET  Protocol  is  to  provide  a 
fairly  general,  bi-directional,  eight-bit  byte  oriented  communications 
facility.  Its  primary  goal  is  to  allow  a  standard  method  of  interfacing 
terminal  devices  and  terminal -oriented  processes  to  each  other.  It  is 
envisioned  that  the  protocol  may  also  be  used  for  terminal -terminal 
communi -cation  ("linking")  and  process-process  communication  (distributed 
computation).  The  Appendices  to  this  volume  contain  DoD  approved  and 
supported  TELNET  options.  It  is  recommended,  but  not  mandatory,  that  these 
options  be  imple-mented  as  useful  adjuncts  to  the  TELNET  protocol.  If 
implemented,  they  are  required  to  be  implemented  as  published  herein. 

4.2  General  considerations.  A  TELNET  connection  is  a  Transmission  Control 
Protocol  (TCP)  connection  used  to  transmit  data  with  interspersed  TELNET 
control  information.  The  TELNET  Protocol  is  built  upon  three  main  ideas: 
first,  the  concept  of  a  Network  Virtual  Terminal;  second,  the  principle  of 
negotiated  options;  and  third,  a  symmetric  view  of  terminals  and  processes. 

4.2.1  Network  Virtual  Terminal  (NVT).  When  a  TELNET  connection  is  first 
establish^,  each  end  is  assumed  to  originate  and  terminate  at  a  Network 
Virtual  Terminal  (NVT).  An  NVT  U  an  imaginary  device  which  provides  a 
standard,  network-wide,  intermediate  .‘epresentation  of  a  canonical  terminal. 
This  eliminates  the  need  for  "server"  and  "user"  hosts  to  keep  information 
about  the  characteristics  of  each  other's  terminals  and  terminal  handling 
conventions.  A1 i  hosts,  both  user  and  server,  map  their  local  device 
characteristics  and  conventions  so  as  to  appear  to  be  dealing  with  an  NVT  over 
the  network,  and  each  can  assume  a  similar  mapping  by  the  other  party.  The 
NVT  i:  intended  to  strike  a  balance  between  being  overly  restricted  (not 
providing  hosts  a  rich  enough  vocabulary  for  mapping  into  their  local 
character  sets),  and  being  overly  inclusive  (penalizing  users  with  modest 
terminals).  The  ""user"  host  is  the  host  to  which  the  physical  terminal  is 
normally  attached,  and  the  "server"  host  is  the  host  which  is  normally 
providing  some  service.  As  an  alternate  point  of  view,  applicable  even  in 
terminal -to-terminal  or  process -to-process  communications,  the  "user"  host  is 
the  host  which  initiated  the  communication. 

4.2.2  Principle  of  negotiated  options.  The  principle  of  ne^tiated  options 

takes  cognizance  of  the  fact  that  many  hosts  will  wish  to  provide  additional 
services  over  and  above  those  available  within  an  NVT,  and  many  users  will 
have  sophisticated  terminals  and  would  like  to  have  elegant,  rather  than 
mini-mal,  services.  Independent  of,  but  structured  withi  he  TELNET  Protocol 
are  various  "options"  that  will  be  sanctioned  and  may  be  with  the  "90, 
DON'T,  WILL.  WON'T"  structure  (discussed  below)  to  allow  .  .  ir  and  server  to 

agree  to  use  a  more  elaborate  (or  perhaps  just  different)  of  conventions 
for  their  TELNET  connection.  Such  options  could  include  changing  the 
character  set,  the  echo  mode.  etc.  The  basic  strategy  for  setting  up  the  use 
of  options  is  to  have  either  party  (or  both)  initiate  a  request  that  some 
option  take  effect.  The  otner  party  may  then  either  accept  or  reject  the 
request.  If  the  request  is  accepted  the  option  immediately  takes  effect;  if 
it  is  rejected  the  associated  aspect  of  the  connection  remains  as  specified 
for  an  NVT.  Clearly,  a  party  may  always  refuse  a  request  to  enable,  and  must 
never  refuse 
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a  request  to  disable  some  option  since  all  parties  must  be  prepared  to  support 

the  NVT,  The  syntax  of  option  negotiation  has  been  set  up  so  that  If  both 

parties  request  an  option  simultaneously,  each  will  see  the  other's  request 
as  the  positive  acknowledgment  of  Its  own. 

4.2.3  Symmetry  of  the  negotiation  syntax.  The  symmetry  of  the  negotiation 
syntax  can  potentially  lead  to  nonterminating  acknowledgment  loops  —  each 
party  seeing  the  Incoming  commands  not  as  acknowledgments  but  as  new  requests 
which  must  be  acknowledged.  To  prevent  such  loops,  the  following  rules 
prevail: 

a.  Parties  may  only  request  a  change  In  option  statue;  l.e. ,  a  party 

may  not  send  out  a  "request**  merely  to  announce  what  mode  It  Is 

In. 

b*  If  a  party  receives  what  appears  to  be  a  request  to  enter  some 
mode  it  Is  already  In,  the  request  should  not  be  acknowledged. 
This  non-response  Is  essential  to  prevent  endless  loops  In  the 
negotiation.  It  Is  required  that  a  response  be  sent  to  requests 
for  a  change  of  mode  —  even  If  the  mode  Is  not  changed. 

c.  Whenever  one  party  sends  an  option  command  to  a  second  party, 
whether  as  a  request  or  an  acknowledgment,  and  use  of  the  option 
will  have  any  effect  on  the  processing  of  the  data  being  sent 
from  the  first  party  to  the  second,  then  the  command  must  be 
Inserted  In  the  data  stream  at  the  point  where  It  Is  desired 
that  It  rake  effect.  Some  time  will  elapse  between  the  trans¬ 
mission  of  a  request  and  the  receipt  of  an  acknowledgment, 
which  nay  be  negative.  Thus,  a  host  may  wish  to  buffer  data, 
after  requesting  an  option,  until  It  learns  whether  the  request 
is  accepted  or  rejected,  In  order  to  hide  the  "uncertainty 
period"  from  the  user. 

4.2.4  Use  of  options.  Option  requests  are  likely  to  flurry  back  and 
forth  when  a  TCLKET  connection  Is  first  established,  as  each  party  attempts 
to  get  the  best  possible  service  from  the  other  party.  Beyond  that,  however, 
options  can  be  used  to  dynamically  modify  the  characteristics  of  the  connec¬ 
tion  to  suit  changing  local  conditions.  For  exa^le,  the  NVT,  as  will  be 
explained  later,  uses  a  transmission  discipline  well  suited  to  the  many 
"line  at  a  time"  applications  such  as  BASIC,  but  poorly  suited  to  the  many 
"character  at  a  time"  applications  such  as  NLS.  A  server  might  elect  to 
devote  the  extra  processor  overhead  required  for  a  "character  at  a  time" 
discipline  when  it  was  suitable  for  the  local  process  and  would  negotiate 

an  appropriate  option.  However,  rather  than  then  being  permanently  burdened 
with  the  extra  processing  overhead,  it  could  switch  (i.e.,  negotiate)  back 
to  NVT  when  the  detailed  control  was  no  longer  necessary.  It  is  possible  for 
requests  initiated  h/  processes  to  stimulate  a  nonterminating  request  loop 
if  the  process  responds  to  a  rejection  by  merely  re-requesting  the  option. 

To  prevent  such  loops  from  occurring,  rejected  requests  should  not  be  repeated 
until  something  changes.  Operationally,  this  can  mean  the  process  is  running 
a  different  program,  or  the  user  has  given  another  cosMand.  or  whatever 
makes  sense  in  the  context  of  the  given  process  and  the  given  option.  A 
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good  rule  of  thunb  is  that  a  re^requeat  should  only  occur  as  a  result  of 
subsequent  lnfor<aation  fron  the  other  end  of  the  connection  or  when  deoanded 
by  local  human  intervention.  Option  designers  should  not  feel  constrained  by 
the  somewhat  limited  syntax  available  for  option  negotiation.  The  Intent  of 
the  simple  syntax  is  to  make  It  easy  to  have  options  —  since  it  Is  corre¬ 
spondingly  easy  to  profess  Ignorance  about  them.  If  some  particular  option 
requires  a  richer  negotiation  structure  than  possible  within  **DO,  DON'T, 

WILL,  WON'T- ,  the  proper  tack  Is  to  use  DO,  DON'T,  WILL,  WON'T"  to  establish 
that  both  parties  understand  the  option,  and  once  this  Is  accompllched  a 
more  exotic  syntax  can  be  used  freely.  For  example,  a  party  might  send  a 
request  to  alter  (establish)  line  length.  If  It  Is  accepted,  then  a  different 
syntax  can  be  used  for  actually  negotiating  the  line  length  —  such  a  "sub- 
negotiation"  might  Include  fields  for  minimum  allowable,  maximum  allowable 
and  desired  line  lengths.  The  Important  concept  Is  that  such  expanded  nego¬ 
tiations  should  never  begin  until  some  prior  (standard)  negotiation  has 
established  that  both  parties  are  capable  of  parsing  the  expanded  syntax. 

Synopsis.  In  suamary,  WILL  XXX  Is  sent,  by  either  party,  to  Indicate 
that  party's  desire  (offer)  to  begin  performing  option  XXX,  DO  XXX  and  DON'T 
XXX  being  Its  positive  and  negative  acknowledgmsots;  similarly,  DO  XXX  is 
sent  to  Indicate  a  desire  (request)  that  the  other  party  (l.e. ,  the  recipient 
of  the  DO)  begin  performing  option  XXX,  WILL  XXX  and  WON'T  XXX  being  the 
positive  and  negative  acknowledgments.  Since  the  NVT  is  what  Is  left  when 
no  options  are  enabled,  the  DON'T  and  WON'T  responses  are  guaranteed  to 
leave  the  connection  in  a  state  which  both  ends  can  handle.  Thus,  all  hosts 
may  Implement  their  TILNET  processes  to  be  totally  unaware  of  options  that 
are  not  supported,  simply  returning  a  rejection  to  (l.e.,  refusing)  any 
option  request  that  cannot  be  understood.  As  much  as  possible,  the  TELNET 
protocol  has  been  made  server-user  symmetrical  so  that  It  easily  and  naturally 
covers  the  user-user  (llidtlng)  and  server-server  (cooperating  procasaes) 
cases.  It  Is  hoped,  but  not  absolutely  required,  that  options  will  further 
this  intent.  In  any  case.  It  Is  explicitly  acknowladgsd  that  symmetry  Is  an 
operating  principle  rather  than  an  Ironclad  rule.  Standard  TELNET  options 
referenced  In  this  document  are  contained  in  Appendices  A-F. 

4.3  The  Nettrork  Virtual  Terminal.  The  Netwock  Virtual  Terminal  (NVT)  la 
a  bl -dir act  tonal  character  device.  The  NVT  has  a  printer  and  a  keyboard. 

The  printer  responda  to  Incoming  data  and  the  keyboard  produces  outgoing 
data  which  Is  sent  over  the  TELNET  connection  and,  if  "echoes"  are  desired, 
to  the  NVT's  printer  as  well.  "Echoes"  will  not  be  expected  to  traverse  tl^ 
network  (although  options  exist  to  enable  a  "remote"  echoing  mode  of  opera¬ 
tion,  no  host  Is  required  to  Implement  this  option).  The  code  set  is  seven- 
bit  USASCIl  in  an  eight-bit  field,  except  as  modified  herein.  Any  code 
conversion  and  timing  eons ids rat lens  are  local  problems  and  do  not  affect 
the  NVT. 

4,3.1  Tranaml salon  of  data.  Altnough  a  TELNET  connection  through  the 
network  is  Intrinsically  full  duplex,  the  NVT  is  to  be  viewed  as  a  half-duplex 
device  operatifg;  in  a  line-buffered  node.  That  is,  unless  and  until  options 
are  negotiated  to  the  contrary,  the  following  default  conditionu  pertain  to 
the  transmission  of  data  over  the  TELNET  connection; 
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4,3. !•!  Accumulation  of  data.  Insofar  as  the  availability  of  local  buffer 
•pace  permits,  data  ahoul'dl^Tc cumulated  in  the  host  where  it  is  generated 
until  a  complete  line  of  data  is  ready  for  transmission,  or  until  some  locally- 
defined  explicit  signal  to  transmit  occurs.  This  signal  could  be  generated 
either  by  a  process  or  by  a  human  user.  The  motivation  for  this  rule  is  the 
high  cost,  to  some  hosts,  of  processing  network  input  interrupts,  coupled 
with  the  default  NVT  specification  that  “echoes**  do  not  traverse  the  network. 
Thus,  it  is  reasonable  to  buffer  some  amount  of  data  at  its  source.  Many 
system*!  take  some  processing  action  at  the  end  of  each  input  line  (even  line 
printers  or  card  punches  frequently  tend  to  work  tkl?  way),  so  the  transmis¬ 
sion  should  be  triggered  at  the  end  of  a  line.  On  the  other  hand,  a  user  or 
process  may  sometimes  find  it  necessary  or  desirable  to  provide  data  which 
does  not  terminate  at  the  end  of  a  line;  therefore  Implementers  are  cautioned 
to  provide  met>»ds  of  locally  signaling  that  all  buffered  data  should  be 
transmitted  immediately. 

4,3. 1.2  TELNET  Go  Ahead  (GA)  command.  When  a  process  has  completed  send¬ 
ing  data  to  an  NVT  printer  and  has  no  queued  input  from  the  NVT  keyboard  for 
further  processing  (l.e.,  when  a  process  at  one  end  of  a  TELNET  connection 
cannot  proceed  without  input  from  the  other  end),  the  process  must  transmit 
the  TELNET  Go  Ahead  (GA)  commard.  This  rule  is  not  intended  to  require  that 
the  TELNET  GA  command  be  sent  from  a  terminal  at  the  end  of  each  line,  since 
server  hosts  do  not  normally  require  a  special  signal  (in  addition  to  end-of- 
llne  or  other  locally-defined  characters)  in  order  to  commence  processing, 
gather,  the  TELNET  GA  is  designed  to  help  a  user’s  local  host  operate  a 
physically  half  duplex  terminal  which  has  a  **lockable**  keyboard  such  as  the 
IBM  2741.  A  description  of  this  type  of  terminal  may  help  to  explain  the 
proper  use  of  the  GA  command.  The  terminal-computer  connection  is  always 
under  control  of  either  the  user  or  the  computer.  Neither  can  unilaterally 
seise  control  from  the  other;  rather  the  controlling  and  must  rellngulsh  its 
control  explicitly.  At  the  terminal  end,  the  hardware  is  constructed  so  as 
to  relinquish  control  each  time  that  a  ‘‘line**  Is  terminated  (l.e.,  when  the 
"New  Line**  key  is  typed  by  the  user).  When  this  occurs,  the  attached  (local) 
computer  processes  the  Input  data,  decides  If  output  should  be  generated, 
and  If  not  returns  control  to  the  terminal.  If  output  should  be  generated, 
control  is  retained  by  the  computer  until  all  output  has  been  transmitted. 

The  difficulties  of  using  this  type  of  terminal  through  the  network  should 
be  obvious.  The  “local**  computer  Is  no  longer  able  to  decide  whether  to 
retain  control  after  seeing  an  end-of-line  signal  or  not;  this  decision  can 
only  he  made  by  the  “remote*  computer  which  la  processing  the  data.  There¬ 
fore,  the  TELNET  GA  commend  provides  a  mechanism  whereby  the  “refsote**  (server? 
computer  can  signal  the  “local*  (user)  computer  that  It  Is  t Itae  to  pass 
control  to  the  user  of  the  terminal.  It  should  be  transmitted  at  thoae 
times,  and  only  at  those  times,  when  the  ^jer  should  be  given  control  of  the 
terminal.  Note  that  premature  tranamleslon  of  the  CA  command  may  result  in 
the  blocking  of  output,  since  the  user  Is  likely  to  assume  that  the  transmit¬ 
ting  system  has  paused,  and  therefore  he  will  fall  to  turn  the  line  around 
manually. 
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4.3.2  Transttlstlon  caution.  The  foregoing,  ©f  courte,  does  not  apply  to 
the  user-to-server  direction  of  conauniciition.  In  this  direction,  GAs  aay 
be  sent  at  any  time,  but  need  not  ever  ha  sent.  Also,  if  the  TELNET  connec¬ 
tion  is  being  used  for  process-to-procass  coaaunlcatlon,  GAs  need  not  be 
sent  in  either  direction.  Finally,  for  temlnal-to-tenilnal  cosaunlcatlon, 

GAs  nsy  be  required  in  neither,  one,  or  both  directions.  If  a  host  plans  to 
support  tentinal-to-teniinal  coaaunicatlon  it  is  suggested  that  the  host 
provide  the  user  with  a  means  of  aanually  signaling  that  it  is  tiae  for  a  GA 
to  be  sent  over  the  TELNET  connection;  this,  however,  is  not  a  requlreaent 
on  the  iapleaenter  of  a  TELNET  process*  The  syaaetry  of  the  TELNET  nodal 
requires  an  NVT  at  each  end  of  the  TELNET  connection,  at  least  conceptually* 

4*4  Standard  representation  of  control  functions*  As  stated  in  paragraph 
4.1,  the  primary  gMl  of  the  TELNET  protocol  is  tirte  provision  of  a  standard 
Interfacing  of  terminal  devices  and  terminal-oriented  processes  through  the 
network.  Early  experiences  with  this  type  of  interconnection  have  shown 
that  certain  functions  are  implemented  by  moat  servers,  but  that  the  methods 
of  Invoking  these  functions  differ  widely.  For  a  human  user  who  Interacts 
with  several  server  systems,  these  differences  are  highly  frustrating* 
telnet,  therefore,  defines  a  standard  representation  for  five  of  these  func¬ 
tions,  as  described  below.  These  standard  representations  have  standard, 
but  not  required,  meanings  (with  the  exception  that  the  Interrupt  Frocess 
(IF)  function  may  be  required  by  other  protocols  which  use  TELNET);  that  is, 
e  system  which  does  net  provide  the  function  to  local  users  need  not  provide 
it  to  network  users  and  may  treat  the  standard  representation  for  the  func¬ 
tion  as  a  No-ops rat ion.  On  the  other  hand,  a  system  which  does  provide  the 
function  to  a  local  user  is  obliged  to  provide  the  same  function  to  a  network 
user  who  transmits  the  standard  representation  for  the  function. 

4.4.1  Interrupt  process  (IF).  Many  systems  provide  a  function  which 
suspends,  interrupts,  aborts,  or  terminates  the  operation  of  a  user  procass* 
This  function  is  frequently  used  when  a  user  believes  his  process  is  in  an 
unending  loop,  or  when  an  unwanted  process  has  been  inadvertently  activated* 

IF  is  the  standard  representation  for  invoking  this  function*  It  should  be 
noted  by  isplementers  chat  IF  may  be  required  by  other  protocols  which  use 
TELNET,  and  therefore  should  be  implemented  if  these  other  protocols  are  to 
be  supported. 

4.4.2  Abort  output  (AO).  Many  systems  provide  a  function  which  allows  a 
process,  which  is  generating  output,  to  run  to  completion  (or  to  reach  the 
same  stopping  point  it  would  reach  if  running  to  completion)  but  without 
sending  the  output  to  the  user's  terminal*  Further,  this  function  typically 
clears  any  output  already  produced  but  net  yet  actually  printed  (or  displayed) 
on  Che  user's  terminal.  AO  is  the  standard  representation  for  invoking  this 
function.  For  example,  some  subsystem  might  normally  accept  a  user's  comsmnd, 
send  a  long  text  string  to  the  user's  terminal  in  response,  and  finally  sig¬ 
nal  readiness  to  accept  the  next  commend  by  sending  a  "prompt "  character 
(preceded  by  <CAKLF»  to  the  user's  terminal.  If  the  AO  were  received 
during  Che  transmission  of  the  text  string,  a  reasonable  implementation 
would  be  to  suppress  Che  remainder  of  the  text  string,  but  transmit  the 
prompt  character  and  the  preceding  <CEXLF>.  (This  is  possibly  in  distinc¬ 
tion  to  the  action  which  might  be  taken  if  an  IF  were  received;  the  IF  mif^t 
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cauae  auppreatlon  of  tha  taxt  atrlng  and  an  axlt  froa  tha  tubayttas.)  I;: 
alttuld  ba  notad,  by  aarvar  ayataaa  which  provlda  thla  function,  that  thara 
■ay  ba  buffara  axtamal  to  tha  ayataa  (In  tha  naMrk  and  tha  uaar'a  local 
boat)  which  ahould  ba  claarad;  tha  appropriata  way  to  do  thia  la  to  tranaait 
tha  "Synch**  aignal  (daacribad  balow)  to  tha  uaar  ayataa. 

4.4.3  Ara  you  thara  (AYT).  Many  ayataaa  provlda  a  function  which  providaa 
tha  uaar  with  aoaa  vlalbla"Ta>g« «  prlntabla)  avldanca  that  tha  ayataa  la  atlll 
up  and  running.  Thla  function  aay  ba  invokad  by  tha  uaar  whan  tha  ayataa  la 
unaxpactadly  "allant **  for  a  long  tlaa,  bacauaa  of  tha  unantlclpatad  (by  tha 
uaar)  langth  of  a  coaputatlon,  an  umiaually  haavy  ayataa  load,  ate*  AYT  la 
tha  atandard  rapraaantatlon  for  Invoking  thla  function. 

4.4.4  Eraaa  charactar  (EC).  Many  ayatasa  provlda  a  function  which  dalataa 
tha  laat  praeadlng  undalatad  charactar  or  "print  poaltlon"  froa  tha  atraaa 
of  data  balng  auppllad  by  tha  uaar.  A  "print  poaltlon"  aay  contain  aavaral 
charactara  which  ara  a  raault  of  ovaratrlkaa,  or  of  aaquancaa  auch  aa  <charl> 
BS  <char2>. ..  Thla  function  la  typically  uaad  to  adit  keyboard  Input  whan 
typing  alatakaa  ara  aada.  EC  la  tha  atandard  rapraaantatlon  for  Invoking 
thla  function. 

4.4.5  Eraaa  llna  (EL).  Many  ayataaa  provide  a  function  which  dalataa  all 
tha  data  In  t^a  currant  "line"  of  Input*  Thla  function  la  typically  uaad 

to  adit  keyboard  input*  EL  la  tha  atandard  rapraaantatlon  for  Invoking  thla 
function* 


4.5  pia  TE^T  "$y/<ch"  elgnal*  Hoat  tlaa*aharlng  ayataaa  provlda  aacha* 
nlaaa  w^lch  allow  a  terminal  uaar  to  regain  control  of  a  "runaway"  procaaa; 
tha  If  and  AO  functlona  daacribad  above  ara  axaaplaa  of  thaaa  aachanlaaa. 

Such  i^taaa,  whan  uaad  locally,  have  accaaa  to  all  of  tha  algnala  auppUad 
by  tha  uaar,  idiathar  thaaa  ara  noiaal  charactara  or  apaclal  "out  of  band" 
algnala  auch  aa  thoaa  auppllad  by  tha  teletype  "StEAE"  key  or  tha  IIM  2741 
"ATTN"  key.  Thla  la  not  nacaaaarlly  true  whan  taralnala  ara  connected  to 
tha  ayataa  through  tha  network;  tha  network 'a  flow  control  aachanlaaa  aay 
cauaa  auch  a  algnal  to  ba  buffered  alaawhara,  for  axaapla  In  tha  uaar*a 
hoat.  To  counter  thla  problaa,  tha  TELNET  "Synch"  aachanlaa  la  introduced. 

A  Synch  algnal  conalata  of  a  TCf  Urgant  notification,  coupled  with  tha  TELNET 
coauMnd  &ATA  NAEK.  Tha  Urgant  notification,  which  la  not  aubject  to  the 
flow  control  parfalnlng  to  tha  TELNET  connection,  la  uaad  to  invoke  apaclal 
handling  of  tha  data  atraaa  by  tha  procaaa  which  racalvaa  it*  In  thla  aoda, 
the  data  atraaa  la  iuMadlataly  acannad  for  "intaraatlng"  algnala  aa  daflnud 
below,  diacardlng  Intervening  data.  Tha  TELNET  caammnd  DATA  MAEK  (ON)  la 
tha  aynchronlalng  aark  in  tha  data  atraaa  which  indlcataa  that  any  apaclal 
algnal  haa  already  occurred  and  tha  raclpiant  can  return  to  normal  procaaalng 
of  tha  data  atraaa.  Tha  Synch  la  aant  via  tha  TCf  aand  operation  with  tha 
Urgant  flag  aat  and  tha  OH  aa  the  laat  (or  only)  data  octet. 
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4.5.1  Sending  several  Synchs.  When  several  Synchs  are  sent  In  rapid 
succession,  the  Urgent  notifications  may  be  merged.  It  Is  not  possible  to 
count  Urgents  since  the  number  received  Mill  be  less  than  or  equal  the  number 
sent.  When  in  normal  mode,  a  ON  is  a  no  operation;  when  in  urgent  modet  It 
signals  the  end  of  the  urgent  processing.  If  TCP  indicates  the  end  of  Urgent 
data  before  the  DM  is  found,  TELNET  should  continue  the  special  handling  of 
the  data  stream  until  the  OH  is  found.  If  TCP  Indicates  more  Urgent  data 
after  the  DM  is  found,  it  can  only  be  because  of  a  subsequent  Synch.  TELNET 
should  continue  the  special  handling  of  the  data  stream  until  another  DM  1$ 
found. 


4.5.2  Interesting  signals.  “Interesting"  signals  are  defined  to  be:  the 
TELNET  standard  representations  of  IP,  AO,  and  AYT  (but  net  EC  or  EL);  the 
local  analogs  of  these  standard  representations  (if  any);  all  other  TE(.NET 
conmands;  other  site-defined  signals  which  can  be  acted  on  without  delaying 
the  scan  of  the  deta  stream. 

4.5.3  One  effect  of  the  Synch  mechanism.  Since  one  effect  of  the  Swch 
tnerhanism  is  the  discarding  or  essentially  all  characters  (except  TELNET 
commands)  between  the  sender  of  the  Synch  and  Its  recipient,  this  mechanism  is 
specified  as  the  standard  way  to  clear  the  data  path  when  that  Is  desired. 

For  example,  if  a  user  at  a  terminal  causes  an  AO  to  be  transmitted,  the 
server  which  receives  the  AO  (If  it  provides  that  function  at  all)  should 
return  a  Synch  to  the  user. 

4.5.4  requirement.  Oust  as  the  TCP  Urgent  notification  1$ 
needed  at  the  TttKET  level  as  an  out-of-band  signal,  so  other  protocols  which 
make  use  of  TELNET  may  reCfUire  a  TELNET  command  which  can  be  viewed  as  an 
out-of-band  signal  at  a  diTferent  level.  By  convention  the  sequence  [IP, 
Synch]  is  to  be  used  as  such  a  signal.  For  example,  suppose  that  some  other 
protocol,  which  uses  TELNET,  defines  the  character  string  STOP  analogously  to 
the  TELNET  command  AO.  Imagine  that  a  user  of  this  protocol  wishes  a  server 
to  process  the  STOP  string,  but  the  connection  Is  blocked  because  the  server 
is  processing  other  commands.  The  user  should  Instruct  his  system  to: 

a.  Send  the  TELNET  IP  character; 

b.  Send  the  TELNET  Synch  sequence,  that  Is;  Send  the  Data  Nark  (ON) 
as  the  only  character  in  a  TCP  urgent  mode  send  operation; 

c.  Send  the  charact«»r  string  STOP;  and 

d.  Send  the  other  protocol's  analog  of  the  TELNET  ON,  if  any. 

The  user  (or  process  acting  on  his  behalf)  must  transmit  the  TELNET  SYNCH 
sequence  of  step  b  above  to  ensure  that  the  TELNET  IP  gets  through  to  the 
server's  TELNET  interpreter.  The  Urgent  should  wake  up  the  TELNET  process; 
the  IP  should  wake  up  the  next  higher  level  process. 


4.6  The  NVT  printer  and  keyboard. 
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4.6.1  NVT  printer  codes.  The  NVT  printer  has  an  unspecified  carriage  width 
and  page  length  and  can  produce  representations  of  all  95  ASCII  graphics 
(codes  32  through  126).  Of  the  33  ASCII  control  codes  (0  through  31  and  127), 
and  the  128  uncovered  codes  (128  through  255),  the  following  have  specified 


meaning  to  the  NVT  printer: 

NAME 

CODE 

MEANING 

a  NULL  (NUL) 

0 

No  Operation 

b.  Line  Feed  (LF) 

10 

Moves  the  printer  to  the  next 
print  line,  keeping  the  same 
horizontal  position. 

c.  Carriage  Return  (CR) 

13 

Moves  the  printer  to  the  left 
margin  of  the  current  line. 

In  addition,  the  following  codes  shall  have  defined,  but  not  required,  effects 
on  the  NVT  printer.  Neither  end  of  a  TELNET  connection  may  assume  that  the 
other  party  will  take,  or  will  have  taken,  any  particular  action  upon  receipt 
or  transmission  of  the  following: 

NAME 

CODE 

MEANING 

d.  BELL  (BEL) 

7 

Produces  an  audible  or  visible 
signal  (which  does  NOT  move  the 
print  head). 

e.  Back  Space  (BS) 

8 

Moves  the  print  head  one 
character  position  towards  the 
left  margin. 

f.  Horizontal  Tab  (HT) 

9 

Moves  the  printer  to  the  next 
horizontal  tab  stop.  It  remains 
unspecified  how  either  party 
determines  or  establishes  where 
such  tab  stops  are  located. 

g.  Vertical  Tab  (VT) 

11 

Moves  the  printer  to  the  next 
vertical  tab  stop.  It  remains 
unspecified  how  either  party 
determines  or  establishes  where 
such  tab  stops  are  located. 

h.  Form  Feed  (FF) 

12 

Moves  the  printer  to  the  top  of 
the  next  page,  keeping  the  same 
horizontal  position. 

All  remaining  codes  do  not  cause  the  NVT  printer  to  take  any  action. 
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4. 6. 1.1  Example  of  code  use.  The  sequence  “CR  LF",  as  defined,  will  cause 
the  NVT  to  be  positioned  at  the  left  margin  of  the  next  print  line  (as  would, 
for  example,  the  sequence  ”LF  CR").  However,  many  systems  and  termi-nals  do 
not  treat  CR  and  LF  independently,  and  will  have  to  go  to  some  effort  to 
simulate  their  effect,  (For  example,  some  terminals  do  not  have  a  CR 
independent  of  the  LF,  but  on  such  terminals  it  may  be  possible  to  simulate  a 
CR  by  backspacing.)  Therefore,  the  sequence  "CR  LF"  must  be  treated  as  a 
single  "new  line"  character  and  used  whenever  their  combined  action  is 
intended;  the  sequence  "CR  NUL"  must  be  used  where  a  carriage  return  alone  is 
actually  desired;  and  the  CR  character  must  be  avoided  in  other  contexts. 

This  rule  gives  assurance  to  systems  which  must  decide  whether  to  perform  a 
"new  line"  function  or  a  multiple-backspace  that  the  TELNET  stream  contains  a 
character  following  a  CR  that  will  allow  a  rational  decision.  Note  that  "CR 
LF"  or  "CR  NUL"  is  required  in  both  directions  (in  the  default  ASCII  mode),  to 
preserve  the  symmetry  of  the  NVT  model.  Even  though  it  may  be  known  in  some 
situations  (e.g.,  with  remote  echo  and  suppress  go  ahead  options  in  effect) 
that  characters  are  not  being  sent  to  an  actual  printer,  nonethe-less,  for  the 
sake  of  consistency,  the  protocol  requires  that  a  NUL  be  inserted  following  a 
CR  not  followed  by  a  LF  in  the  data  stream.  The  converse  of  this  is  that  a 
NUL  received  in  the  data  stream  after  a  CR  (in  the  absence  of  options 
negotiations  which  explicitly  specify  otherwise)  should  be  stripped  out  prior 
to  applying  the  NVT  to  local  character  set  mapping. 

4. 6. 1.2  ASCII  code  generation.  The  NVT  keyboard  has  keys,  or  key 
combinations,  or  key  sequences,  for  generating  all  128  ASCII  codes.  Note  that 
although  many  have  no  effect  on  the  NVT  printer,  the  NVT  keyboard  is  capable 
of  generating  them. 

4. 6. 1.3  Additional  codes.  In  addition  to  these  codes,  the  NVT  keyboard 
shall  be  capable  o^  generating  the  following  additional  codes  which,  except  as 
noted,  have  defined,  but  not  required,  meanings.  The  actual  code  assignments 
for  these  "characters"  are  in  the  TELNET  Command  section,  because  they  are 
viewed  as  being,  in  some  sense,  generic  and  should  be  available  even  when  the 
data  stream  is  interpreted  as  being  some  other  character  set. 

4. 6. 1.3.1  Synch.  This  key  allows  the  user  to  clear  his  data  path  to  the 
other  party.  The  activation  of  this  key  causes  a  DM  (see  command  section)  to 
be  sent  in  the  data  stream  and  a  TCP  Urgent  notification  is  associated  with 
it.  The  pair  DM-Urgent  is  to  have  required  meaning  as  defined  previously. 

4. 6. 1.3. 2  Break  (BRK).  This  code  is  provided  because  it  is  a  signal 
outside  the  ASCII  set  which  is  currently  given  local  meaning  within  many 
systems.  It  is  intended  to  indicate  that  the  Break  Key  or  the  Attention  Key 
was  hit.  Note,  however,  that  this  is  intended  to  provide  a  129th  code  for 
systems  which  require  it,  not  as  a  synonym  for  the  IP  standard  representation. 

4. 6. 1.3. 3  Interrupt  pryess  (IP).  Suspend,  interrupt,  abort  or  terminate 
the  process  to  which  the  NVT  is  connected.  Also,  part  of  the  out-of-band 
signal  for  other  protocols  which  use  TELNET. 
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4.6. 1.3.4  Abort  output  (AO).  Allow  the  current  process  to  (appear  to) 
run  to  completion,  but  do  not  send  its  output  to  the  user.  Also,  send  a 
Synch  to  the  user. 

4.6. 1.3.5  Are  you  there  (AYT).  Send  back  to  the  NVT  some  visible  (l,e. , 
printable)  evidence  that  the  AYT  was  received. 

4.6. 1.3.6  Erase  character  (EC).  The  recipient  should  delete  the  last 
preceding  undeleted  character  or  "print  position"  from  the  data  stream. 

4.6. 1.3.7  Erase  line  (EL).  The  recipient  should  delete  characters  from 
the  data  stream  back  to,  but  not  including,  the  last  "CR  LF"  sequence  sent 
over  the  TELNET  connection. 

4. 6. 1.3.8  Intent  of  additional  codes.  The  spirit  of  these  "extra"  keys, 
and  also  the  printer  format  effectors,  is  that  they  should  represent  a 
natural  extension  of  the  mapping  that  already  must  be  done  from  "NVT"  into 
"local".  Just  as  the  NVT  data  byte  68  (104  octal)  should  be  mapped  into 
whatever  the  local  code  for  "uppercase  D"  is,  so  t\\u  EC  character  should  be 
mapped  Into  whatever  the  local  "Erase  Character"  function  is.  Further,  Just 
as  the  mapping  for  124  (174  octal)  is  somewhat  arbitrary  in  an  environment 
that  has  no  "vertical  bar"  character,  the  EL  character  may  have  a  somewhat 
arbitrary  mapping  (or  none  at  all)  if  there  is  no  local  "Erase  Line"  facility. 
Similarly  for  format  effectors*  if  the  terminal  actually  does  have  a  "Verti-* 
cal  Tab",  then  the  mapping  for  VT  is  obvious,  and  only  when  the  terminal 

does  not  have  a  vertical  tab  should  the  effect  of  VT  be  unpredictable. 

4.7  TELNET  comamnd  structure.  All  TELNET  commands  consist  of  at  least  a 
two  byte  sequence:  the  ^Interpret  as  Command"  (lAC)  escape  character  followed 
by  the  code  for  the  command.  The  commands  dealing  with  option  negotiation 
are  three  byte  sequences,  the  third  byte  being  the  code  for  the  option  refer- 
enced.  This  format  was  chosen  so  that  as  more  comprehensive  use  of  the 
"data  space"  is  made  —  by  negotiations  from  the  basic  NVT,  of  course  — 
collisions  of  data  bytes  with  reserved  command  values  will  be  minimised,  all 
such  collisions  requiring  the  Inconvenience,  and  inefficiency,  of  "escaping" 
the  data  bytes  into  the  stream.  With  the  current  set-up,  only  the  lAC  need 
be  doubled  to  be  sent  as  data,  and  the  other  253  codes  may  be  passed  trans¬ 
parently. 


4.7.1  TELNET  commands  defined.  The  following  are  the  defined  TELNET 
comands.  Note  that  these  codes  and  code  sequences  have  .’he  indicated  meaning 
only  when  immediately  preceded  by  an  lAC. 


CODE 

SE 

240 

End  of  subnegotiatlon  parameters. 

NOP 

241 

No  operation. 

Data  Hark 

242 

The  data  stream  portion  of  a  Synch 
This  should  always  be  accompanied 
by  a  TCP  Urgent  notification. 

13 


1-447 


DDN  PROTOCOL  HANDBOOK  VOLUME  ONE 


1985 


MIL-STD-1782 
10  May  1984 


d. 

Break 

243 

NVT 

character  BRK. 

e. 

Interrupt  Process 

244 

The 

function  IP. 

f. 

Abort  output 

245 

The 

function  AO. 

g. 

Are  You  There 

246 

The 

function  AYT. 

h. 

Erase  character 

247 

The 

function  EC. 

i. 

Erase  Line 

248 

The 

function  EL. 

.1. 

Go  ahead 

249 

The 

GA  signal. 

k. 

SB 

250 

Indicates  that  what  follows  is 

•ubnegotlatlon  of  the  Indicated 
option. 


1.  WILL  (option  code)  251  Indicatea  the  desire  to  begin  per- 

foming,  or  confimation  that  you 
are  now  perfon>ing»  the  indicated 
option. 

Q.  WON'T  (option  code)  252  Indicates  the  refusal  to  perforv*  or 

continue  perfoming,  the  indicated 
option. 

n.  DO  (option  code)  253  Indicates  the  request  thst  the  other 

party  perfom,  or  confiraation  that 
you  are  e^cting  the  other  party  to 
perfom,  the  indicated  option. 

o.  DON'T  (option  code)  254  Indicates  the  'deaand  that  the  ottier 

party  stop  perfoming,  or  confiraatiou 
that  you  are  no  longer  expecting  the 
other  party  to  perfora»  the  indicated 
option. 

P*  lAC  255  Data  By^  255. 

4.8  Connection  establishaent.  The  TELNET  TCP  connection  is  established 
between  the  user’s  port  U  and  the  server's  poTc  L.  The  server  listens  on 
its  well  known  port  L  for  such  connections.  Since  a  TCP  connection  is  full 
duplex  and  identified  by  the  pair  of  ports,  the  server  can  engage  in  nany 
sifwltsneous  connections  Involving  its  port  L  and  different  user 
ports  U. 

4.8.1  Port  assignaent.  When  used  for  reaote  user  access  to  service  hosts 
(i.e.,  renote  terminal  access)  this  protocol  is  assigned  server  port  23  (27 
octal).  That  is  L«23. 
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APPENDIX  A 

TELNET  BINARY  TRANSMISSION 

10.  Command  name  and  code. 

TRANSMIT-BINARY  0 

20.  Command  meanings. 

20.1  lAC  WILL  TRANSMIT-BINARY.  The  sender  of  this  command  REQUESTS 
permission  to  begin  transmitting,  or  confirms  that  it  will  now  begin 
transmitting  characters  which  are  to  be  interpreted  as  8  bits  of  binary  data 
by  the  receiver  of  the  data. 

20.2  lAC  W0N*T  TRANSMIT»BINARY.  If  the  connection  is  already  being 
operated  In  binary  transmission  mode,  the  sender  of  this  command  DEMANDS  to 
begin  transmitting  data  characters  which  are  to  be  interpreted  as  standard  NVT 
ASCII  characters  by  the  receiver  of  the  data.  If  the  connection  is  not 
already  being  operated  in  binary  transmission  mode,  the  sender  of  this  command 
REFUSES  to  begin  transmittino  characters  which  are  to  be  interpreted  as  binary 
characters  by  the  receiver  of  the  data  (i.e.,  the  sender  of  the  data  demands 
to  continue  transmitting  characters  in  its  present  mode).  A  connection  Is 
being  operated  in  binary  transmission  mode  only  when  one  party  has  requested 
it  and  the  other  has  acknowledged  it. 

20.3  lAC  DO  TRANSMIT-BINARY.  The  sender  of  this  conwand  REQUESTS  that  the 
sender  of  the  data  start  transmitting,  or  confirms  that  the  sender  of  data  is 
expected  to  transmit,  characters  which  are  to  be  Interpreted  as  8  bits  of 
binary  data  (i.e.,  by  the  party  sending  this  command). 

20.4  lAC  DON*T  TRANSMIT-BINARY.  If  the  connection  is  already  being 
operated  in  binary  transmission  mode,  the  sender  of  this  command  DEMANDS  that 
the  sender  of  the  data  start  transmitting  characters  which  are  to  be 
Interpreted  as  standard  NVT  ASCII  characters  by  the  receiver  of  the  data 
(i.e.,  the  party  sending  this  command).  If  the  connection  is  not  already 
being  operated  in  binary  transmission  mode,  the  sender  of  this  command  DEMANDS 
that  the  sender  of  data  continue  transmitting  characters  which  are  to  be 
interpreted  in  the  present  mode.  A  connection  is  being  operated  In  binary 
transmission  mode  only  when  one  party  has  requested  it  and  the  other  has 
acknowledged  it. 

30.  Default. 

WON’T  TRANSMIT-BINARY 
DON’T  TRANSMIT-BINARY 

The  connection  is  not  operated  in  binary  mode- 
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40.  Motivation  for  the  option.  It  is  sometimes  useful  to  have  available  a 
binary  transmission  path  wuhin  TELNET  without  having  to  utilize  one  of  the 
more  efficient,  higher  level  protocols  providing  binary  transmission  {such  as 
the  File  Transfer  Protocol).  The  use  of  the  lAC  prefix  within  the  basic 
TELNET  protocol  provides  the  option  of  binary  transmission  in  a  natural  way, 
requiring  only  the  addition  of  a  mechanism  by  which  the  parties  involved  can 
agree  to  INTERPRET  the  characters  transmitted  over  a  TELNET  connection  as 
binary  data. 

50.  Description  of  the  option.  With  the  binary  transmission  option  in 
effect,  the  receiver  should  interpret  characters  received  from  the  transmitter 
which  are  not  preceded  with  lAC  as  8  bit  binary  data,  with  the  exception  of 
lAC  followed  by  lAC  which  stands  for  the  8  bit  binary  data  with  the  decimal 
value  255.  lAC  followed  by  an  effective  TELNET  comnand  (plus  any  additional 
characters  required  to  complete  the  command)  Is  still  the  command  even  with 
the  binary  transmission  option  in  effect.  lAC  followed  by  a  character  which 
is  not  a  defined  TELNET  command  has  the  same  meaning  as  lAC  followed  by  NOP, 
although  an  lAC  followed  by  an  undefined  command  should  not  normally  be  sent 
in  this  mode. 

60.  Implementation  suggestions.  It  is  foreseen  that  Implementations  of  the 
binary  transmission  option  will  choose  to  refuse  some  other  options  (such  as 
the  EBCDIC  transmission  option)  while  the  binary  transmission  option  is  in 
effect.  However,  if  a  pair  of  hosts  can  understand  being  in  binary 
transmission  mode  simultaneous  with  being  in,  for  example,  echo  mode,  then  it 
is  alright  if  they  negotiate  that  combination.  The  meanings  of  WON'T  and 
DON'T  are  dependent  upon  whether  the  connection  is  presently  being  operated  in 
binary  mode  or  not.  Consider  a  connection  operating  in  EBCDIC  mode  which 
involves  a  system  which  has  chosen  not  to  implement  any  knowledge  of  the 
binary  command.  If  this  system  were  to  receive  a  00  TRANSMIT -BINARY,  it  would 
not  recognize  the  TRANSMIT-BINARY  option  and  therefore  would  return  a  WON'T 
TRANSMIT-BINARY.  If  the  default  for  the  WON'T  TRANSMIT-BINARY  were  always  NVT 
ASCII,  the  sender  of  the  DO  TRANSMIT-BINARY  would  expect  the  recipient  to  have 
switched  to  NVT  ASCII,  whereas  the  receiver  of  the  DO  TRANSMIT-BINARY  would 
not  make  this  interpretation.  Thus,  we  have  the  rule  that  when  a  connection 
is  not  presently  operating  in  binary  mode,  the  default  (i.e.,  the 
interpretation  of  WON'T  and  DON'T)  is  to  continue  operating  in  the  current 
mode,  whether  that  is  NVT  ASCII,  EBCDIC,  or  some  other  mode.  This  rule, 
however,  is  not  applied  once  a  connection  Is  operating  in  a  binary  mode  (as 
agreed  to  by  both  ends);  this  would  require  each  end  of  the  connection  to 
maintain  a  stack,  containing  all  of  the  encoding-method  transitions  which  had 
previously  occurred  on  the  connection,  in  order  to  properly  interpret  a  WON'T 
or  DON'T.  Thus,  a  WON'T  or  DON'T  received  after  the  connection  is  operating 
in  binary  mode  causes  the  encoding  method  to  revert  to  NVT  ASCII. 
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70.  Binary  transmission  mode.  It  should  be  remembered  that  a  TELNET 
connection  is  a  two  way  communication  channel.  The  binary  transmission  mode 
must  be  negotiated  separately  for  each  direction  of  data  flow,  if  that  is 
desired.  Implementation  of  the  binary  transmission  option,  as  is  the  case 
with  implementations  of  all  other  TELNET  options,  must  follow  the  loop 
preventing  rules  given  in  the  General  Considerations  section  of  the  TELNET 
Protocol  Specification.  Consider  now  some  issues  of  binary  transmission  both 
to  and  from  both  a  process  and  a  terminal: 

70.1  Binary  transmission  from  a  terminal.  The  implementer  of  the  binary 
transmission  option  should  consider  how  (or  whether)  a  terminal  transmitting 
over  a  TELNET  connection  with  binary  transmission  in  effect  is  allowed  to 
generate  all  eight  bit  characters,  ignoring  parity  considerations,  etc.,  on 
input  from  the  terminal. 

70.2  Binary  transmission  to  a  process.  The  implementer  of  the  binary 
transmission  option  should  consider  how  (or  whether)  all  characters  are  passed 
to  a  process  receiving  over  a  connection  with  binary  transmission  in  effect. 

As  an  example  of  the  possible  problem,  T0P$-20  intercepts  certain  characters 
(e.g.,  ETX,  the  terminal  control -C)  at  monitor  level  and  does  not  pass  them  to 
the  process. 

70.3  Binary  transmission  from  a  process.  The  implementer  of  the  binary 
transmission  option  should  consider  how  (or  whether)  a  process  transmitting 
over  a  connection  with  binary  transmission  in  effect  is  allowed,  to  send  all 
eight  bit  characters  with  no  characters  intercepted  by  the  rooniW  and  changed 
to  other  characters.  An  example  of  such  a  conversion  may  be  found  in  the 
TOPS-20  system  where  certain  non-printing  characters  art  normally  converted  to 
a  Circumflex  (up-arrow)  followed  by  a  printing  character. 

70. 4  Binary  transmission  to  a  terminal.  The  Implementer  of  the  binary 
transmission  option  should  consider  Ttow  (or  whether)  all  characters  received 
over  a  connection  with  binary  transmission  in  effect  are  sent  to  a  local 
terminal.  At  issue  may  be  the  addition  of  timing  characters  normally  inserted 
locally,  parity  calculations,  and  any  normal  code  conversion. 
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APPENDIX  8 
TELNET  ECHO  OPTION 


10.  Command  name  and  code. 

ECHO  1 

20.  Command  meanings. 

I AC  WILL  ECHO.  The  sender  of  this  command  REQUESTS  to  begint  or 
con-firms  that  It  will  now  begin,  echoing  data  characters  it  receives  over  the 
TELNET  connection  back  to  the  sender  of  the  data  characters. 

20*2  lAC  W0N*T  ECHO.  The  sender  of  this  command  DEMANDS  to  stop,  or 
refuses  to  start,  echoing  the  data  characters  it  receives  over  the  TELNET 
connection  back  to  the  sender  of  the  data  characters. 

20*3  lAC  DO  ECHO.  The  sender  of  this  command  REQUESTS  that  the  receiver  of 
this  command  begin  echoing,  or  confirms  that  the  receiver  of  this  command  is 
expected  to  echo,  data  characters  it  receives  over  the  TELNET  connection  back 
to  the  sender. 

20*4  lAC  DON’T  ECHO.  The  sender  of  this  command  DEMANDS  the  receiver  of 
this  command  stop,  or not  start,  echoing  data  characters  it  receives  over  the 
TELNET  connection. 

30.  Default. 

WON'T  ECHO 
DON'T  ECHO 

No  echoing  is  done  over  the  TELNET  connection. 

40.  Motivation  for  the  option.  TTie  NVT  has  a  printer  and  a  keyboard  which 
are  nominally  interconnected  so  that  "echoes'*  need  never  traverse  the  network; 
that  is  to  say,  the  NVT  nominally  operates  in  a  mode  where  characters  typed  on 
the  keyboard  are  (by  some  means)  locally  turned  around  and  printed  on  the 
printer.  In  highly  interactive  situations  it  is  appropriate  for  the  remote 
process  (command  language  interpreter,  etc.)  to  which  the  characters  are  being 
sent  to  control  the  way  they  are  echoed  on  the  printer.  In  order  to  support 
such  Interactive  situations,  it  is  necessary  that  there  be  a  TELNET  option  to 
allow  the  parties  at  the  two  ends  of  the  TELNET  connection  to  agree  that 
characters  typed  on  an  NVT  keyboard  are  to  be  echoed  by  the  party  at  the  other 
end  of  the  TELNET  connection. 
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5.0  Description  of  the  option.  When  the  echoing  option  Is  in  effect,  the 
party  at  the  end  performing  the  echoing  la  expected  to  transmit  (echo)  data 
characters  It  receives  hack  to  the  sender  of  the  data  characters*  The  option 
does  not  require  that  the  characters  echoed  he  exactly  the  characters  received 
(for  example,  a  number  of  systems  echo  the  ASCII  ESC  character  with  something 
other  than  the  ESC  character).  When  the  echoing  option  Is  not  In  effect,  the 
receiver  of  data  characters  should  not  echo  them  hack  to  the  sender;  this, 
of  course,  does  not  prevent  the  receiver  from  responding  to  data  characters 
received.  The  normal  TELNET  connection  Is  two  way.  That  Is,  data  flows  In 
each  direction  on  the  connection  Independently;  and  neither,  either,  or  both 
directions  may  be  operating  simultaneously  In  echo  mode.  There  are  five 
reasonable  modes  of  operation  for  echoing  on  a  connection  pair: 


mocess  i 


smoctui 


Neither  end  echoes 


pmociss  1 


) 


seoctMi 


One  end  echoes  for  itself 


smoctu  I 


i: 


smoettst 


One  end  echoes  for  the  other 


seoctts 


— ( 


swocttaa 


Both  ends  echo  for  themselves 


smoctss  I 


:k 


PROCttSI 


One  end  echoes  for  both  endn 

riCUBC  1.  Five  reasonable  modes  of  operation  for 
echoing  on  a  connection  pair. 
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This  option  provides  the  capability  to  decide  on  whether  or  not  either  end 
will  echo  for  the  other.  It  does  not,  however,  provide  any  control  over 
whether  or  not  an  end  echoes  for  itself;  this  decision  must  be  left  to  the 
sole  discretion  of  the  systems  at  each  end  (although  they  may  use  information 
regardinq  the  state  of  "remote"  echoing  negotiations  in  making  this 
decision).  If  BOTH  hosts  enter  the  mode  of  echoing  characters  transmitted  by 
the  other  host,  then  any  character  transmitted  in  either  direction  will  be 
"echoed"  back  and  forth  indefinitely.  Therefore,  care  should  be  taken  in  each 
implementation  that  if  one  site  is  echoing,  echoing  is  not  permitted  to  be 
turned  on  at  the  other.  As  discussed  in  Section  4,  both  parties  to  a 
full-duplex  TELNET  connection  initially  assume  each  direction  of  the 
connection  is  being  operated  in  the  default  mode  which  is  non-echo  (non-echo 
Is  not  using  this  option,  and  the  same  as  DON'T  ECHO,  WON'T  ECHO).  If  either 
party  desires  himself  to  echo  characters  to  the  other  party  or  for  the  other 
party  to  echo  characters  to  him,  that  party  gives  the  appropriate  command 
(WILL  ECHO  or  00  ECHO)  and  waits  (and  hopes)  for  acceptance  of  the  option.  If 
the  request  to  operate  the  connection  in  echo  mode  is  refused,  then  the 
connection  continues  to  operate  in  non -echo  mode.  If  the  request  to  operate 
the  connection  in  echo  mode  is  accepted,  the  connection  is  operated  in  echo 
mode.  After  a  connection  has  been  changed  to  echo  mode,  either  party  may 
demand  that  it  revert  to  non-echo  mode  by  giving  the  appropriate  DON'T  ECHO  or 
WON'T  ECHO  command  (which  the  other  party  must  confirm  thereby  allowing  the 
connection  to  operate  in  non-echo  mode).  Just  as  each  direction  of  the  TELNET 
connec-tion  may  be  put  in  remote  echoing  mode  independently,  each  direction  of 
the  TELNET  connection  must  be  removed  from  remote  echoing  mode  separately. 

60.  Implyientation  of  the  option.  Implementations  of  the  echo  option,  as 
implemeniations  of" all  oilher  uLHfT  options,  must  follow  the  loop  preventing 
rules  given  in  the  General  Requirements  section  of  the  TELNET  Protocol 
Standard.  Also,  so  that  switches  between  echo  and  non-echo  mode  can  be  made 
with  minimal  confusion  (momentary  double  echoing,  etc.),  switches  in  mode  of 
operation  should  be  made  at  times  precisely  coordinated  with  the  reception  and 
transmission  of  echo  requests  and  demands.  For  instance,  if  one  party 
responds  to  a  DO  ECHO  with  a  WILL  ECHO,  all  data  characters  received  after  the 
DO  ECHO  should  be  echoed  and  the  WILL  ECHO  should  immediately  precede  the 
first  of  the  echoed  characters.  The  echoing  option  alone  will  normally  net  be 
sufficient  to  effect  what  is  commonly  understood  to  be  remote  computer  echoing 
of  characters  typed  cn  a  terminal  keyboard— the  SUPPRESS-GO  AHEAD  option  will 
normally  have  to  be  invoked  in  conjunction  with  the  ECHO  option  to  effect 
character -at -a -time  remote  echoing. 

60.1  A  swle  implementation  of  the  option.  The  following  is  a  description 
of  a  possible  implementation  for  a  sample  user  system  called  "UHOST".  A 
possible  implementation  could  be  that  for  each  user  terminal,  the  UHOST  would 
keep  three  state  bits:  whether  the  terminal  echoes  for  itself  (UHOST  ECHO 
always)  or  not  (ECHO  mode  possible),  whether  the  (human)  user  prefers  to 
operate  in  ECHO  mode  or  in  non -ECHO  mode,  and  whether  the  connection  from  this 
terminal  to  the  server  is  in  ECHO  or  non-ECHO  mode.  We  will  call  these  th-^ee 
bits  P(hysical),  D(es1red},  and  A(ctual).  When  a  terminal  dials  up  the  UHOST 
the  P-bit  is  set  appropriately,  the  D-bit  is  set  equal  to  it,  and  the  A-bit  is 
set  to  non-ECHO.  The  P-bit  and  0-bit  may  be  manually  reset  by 
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direct  coMoandt  if  the  uaer  to  detlrtt.  For  extaple,  a  user  in  Hawaii  on  a 
"full-duplex**  terod.nal,  would  choose  not  to  operate  in  ECHO  aode»  regardless 
of  the  preference  of  a  aainland  server.  He  should  direct  the  UHOST  to  change 
his  D-bit  froa  ECHO  to  non-ECHO.  When  a  connection  Is  opened  froo  Che  UHOST 
terainal  to  a  server,  the  UHOST  would  send  the  server  a  DO  ECHO  coaaand  If 
the  MIN  (with  non-ECHO  less  than  ECHO)  of  the  P-  and  D-bits  is  different 
from  the  A-bit.  If  a  WON'T  ECHO  or  WILL  ECHO  arrives  froa  Che  server,  Che 
UHOST  will  set  the  A-bit  to  the  MIN  of  the  received  request,  the  P-bit,  and 
the  D-bit.  If  this  changes  the  state  of  the  A-bit,  the  UHOST  will  send  off 
the  appropriate  acknowledgaent ;  if  it  does  not,  then  the  UHOST  will  send  off 
the  appropriate  refusal  if  not  changing  aeant  that  it  had  Co  deny  the  request 
(i.e.,  the  MIN  of  the  P-and  D-bits  was  less  than  the  received  A-request).  If 
while  a  connection  is  open,  the  UHOST  terainal  user  changes  either  the  P-biC 
or  D-bit,  the  UHOST  will  repeat  Che  above  tests  and  send  off  a  DO  ECSO  or 
DON'T  ^HO,  if  necessary.  When  Che  connection  is  closed,  the  UHOST  would 
reset  the  A-bit  to  Indicate  UHOST  echoing.  While  Che  UROST's  iapleaentaCion 
would  not  involve  DO  ECHO  or  DON'T  ECHO  coaaands  being  sent  to  the  server 
except  when  the  connection  is  opened  or  the  user  explicitly  changes  his 
echoing  node,  bigger  hosts  night  invoke  such  node  priCches  quite  frequently. 
For  Instance,  while  a  line-at-a-tine  systen  were  running,  the  server  nl^hc 
attenpt  to  put  the  user  in  local  echo  node  by  sending  the  WON'T  ECHO  connsf^ 
to  the  user;  but  while  a  character-et-a-tine  systen  were  running,  the  server 
night  attenpt  to  invoke  renote  echoing  for  the  user  by  sending  Che  WILL  ECHO 
connand  to  Che  user.  Furchemore,  while  the  UHOST  will  never  send  a  WILL 
ECHO  connand  and  will  only  send  a  WON'T  ECHO  to  refuse  a  server  sent  DO  ECHO 
connand,  a  server  host  night  often  send  Che  WILL  and  WON'T  ECHO  ecnnands. 
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APPENDIX  C 

TELNET  SUPPRESS  GO  AHEAD  OPTION 

10.  Cornmand  name  and  code. 

SUPPRESS-GO-AHEAO  3 

20.  Conwand  meanings. 

20.1  lAC  HILL  $UPPR£SS»GO«AHEAD.  The  sender  of  this  conwand  requests 
permission  to  beg^n  suppressing  transmission  of  the  TELNET  GO  AHEAD  (6A) 
character  when  transmitting  data  characters,  or  the  sender  of  this  command 
confirms  it  will  now  begin  suppressing  transmission  of  GAs  with  transmitted 
data  characters. 

20.2  lAC  W0N*T  SUPPRES$*QO-AHEAD.  The  sender  of  this  command  demands  to 
begin  transmUi^hg,  or  to  continue  transmitting,  the  GA  character  when 
trans-mi tting  data  characters. 

20.3  lAC  DO  $UPPRESS-60*AHEAD.  The  sender  of  this  conwannd  requests  that 
the  sender  of  data  start  suppressing  GA  when  transmitting  data,  or  the  sender 
of  this  command  confirms  that  the  sender  of  data  is  expected  to  suppress 
transmission  of  GAs. 

20.4  lAC  00N*T  SUPPRES$-G0-AHEAD.  The  sender  of  this  command  demands  that 
the  receiver  of  the  conwand  start  or  continue  transmitting  GAs  when 
transmitting  data. 

30.  Default. 


WON'T  SUPPRESS-GO-AHEAD 
DON'T  SUPPRESS-GO-AHEAD 
Go  aheads  are  transmitted. 

40.  Motivation  for  the  option.  While  the  NVT  nominally  follows  a  half 
duplex  protocol  compleie  with  a  GO  AHEAD  signal,  there  is  no  reason  why  a  full 
duplex  connection  between  a  full  duplex  terminal  and  a  host  optimized  to 
handle  full  duplex  terminals  should  be  burdened  with  the  GO  AHEAD  signal. 
Therefore,  it  is  desirable  to  have  a  TELNET  option  with  which  parties 
in»volved  can  agree  that  one  or  the  other  or  both  should  suppress  transmission 
of  GO  AHEADS. 

50.  Descr 1 pt i on  of  the  option.  When  the  SUPPRESS-GO-AHEAD  option  is  in 
effect  on  tKe  connection  between  a  sender  of  data  and  the  receiver  of  the 
data,  the  sender  need  not  transmit  GAs.  It  seems  probable  that  the  parties  to 
the  TELNET  connection  will  suppress  GO  AHEAD  in  both  directions  of  the  TELNET 
connection  if  GO  AHEAD  is  suppressed  at  all;  but,  nonetheless,  it 
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must  be  suppressed  in  both  directions  independently.  With  the 
SUPPRESS-GO-AHEAD  option  in  effect,  the  lAC  GA  command  should  be  treated  as  a 
NOP  if  received,  although  lAC  GA  should  not  normally  be  sent  in  this  mode. 

60.  Imp 1 emen t at i on  cons i derat ions.  As  the  SUPRESS-QO-AHEAO  option  is  sort 

of  the  opposite  of  a  llne-at-a  time  mode,  the  sender  of  data  which  is 
suppressing  GO  AHEAOs  should  attempt  to  actually  transmit  characters  as  soon 
as  possible  (i.e.,  with  minimal  buffering)  consistent  with  any  other 
agreements  which  are  in  effect.  In  many  TELNET  implementations  it  will  be 
desirable  to  couple  the  SUPPRESS-GO*AHEAO  option  to  the  Kho  option  so  that 
when  the  echo  option  is  in  effect,  the  SUPPRESS-GO-AHEAD  option  is  in  effect 
simultaneously:  both  of  these  options  will  normally  have  to  be  in  effect 
simultaneously  to  effect  what  is  commonly  understood  to  be  character-at-a  time 
echoing  by  the  remote  computer. 
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APPENDIX  0 
TELNET  STATUS  OPTION 


10.  Command  name  and  code. 

STATUS  S 

20.1  Command  meanings.  This  option  applies  separately  to  each  direction  of 
data  flow. 

20.1  lAC  WILL  STATUS.  The  sender  of  WILL  status  agrees  to  send  status 
Information,  spontaneously  or  In  response  to  future  requests. 

20.2  I AC  WON'T  STATUS.  Sender  refuses  to  carry  on  any  further  discussion 
cf  the  current  status  of  options. 

20.3  I AC  DO  STATUS.  The  sender  of  DO  wishes  to  be  able  to  send  request  for 
status  of  in  option  Information  or  confirms  that  he  is  willing  to  send  such 
requests . 

20*^  I AC  DON'T  STATUS.  Sender  refuses  to  carry  on  any  further  discussion 
or  the  current  status  of  options. 

20.5  I AC  SB  STATUS  SEND  lAC  SE.  Sender  requests  receiver  to  transmit  his 
(the  receiver's)  percept  lion  of  the  current  status  of  TELNET  options.  The  code 
for  SEND  is  1. 

20.6  lAC  SB  STATUS IS... lAC  SE.  Sender  is  stating  his  perception  of  the 
current  status  of  TELNET  options.  The  code  for  IS  is  0. 

30.  Default. 

DON'T  STATUS,  WON'T  STATUS 

The  current  status  of  options  will  not  be  discussed. 

40.  Motivation  for  This  option  allows  a  user /process  to  verify 

the  current  status  of  TELNET  option.,  (e.g.,  echoing)  as  viewed  by  the  person/ 
process  on  the  other  end  of  the  TELNET  connection.  Simply  renegotiating 
options  could  lead  to  the  non terminating  request  loop  problem  discussed  in 
paragraph  4.2.3.  This  option  fits  into  the  normal  structure  of  TELNET  options 
by  deferring  the  actual  transfer  of  status  information  to  the  SB  command. 

50.  Description  of  the  option.  WILL  and  DO  are  used  only  to  obtain  and 
grant  permission  i"or  future  discussion.  The  actual  exchange  of  status 
information  occurs  within  option  suoconinands  (lAC  SB  STATUS...).  Once  the  two 
hosts  have  exchanged  a  WILL  and  a  00,  the  sender  of  the  WILL  STATUS  is  free  to 
transmit  status  information,  spontaneously  or  in  response  to  a  request  from 


25 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1Q85 


MIL-STD-1782 
10  May  1984 

the  sender  of  the  DO.  At  worst,  this  may  lead  to  transmitting  the  information 
twice.  Only  the  sender  of  the  DO  may  send  requests  (lAC  SB  STATUS  SEND  lAC 
SE)  and  only  the  sender  of  the  WILL  may  transmit  actual  status  information 
(within  an  lAC  SB  STATUS  IS  ...  lAC  SE  command).  IS  has  the  subcommands  WILL, 
DO  and  SB.  They  are  used  EXACTLY  as  used  during  the  actual  negotiation  of 
TELNET  options,  except  that  SB  is  terminated  with  SE,  rather  than  lAC  SE. 
Transmission  of  SE,  as  a  regular  data  byte,  is  accomplished  by  doubling  the 
byte  (SE  SE).  Options  that  are  not  explicitly  described  are  assumed  to  be  in 
their  default  states.  A  single  lAC  SB  STATUS  IS...IAC  SE  describes  the 
condition  of  ALL  options. 

60.  Example  of  option  application.  The  following  is  an  example  of  use  of 
the  option: 

Hostl :  lAC  DO  STATUS 

Host2:  lAC  WILL  STATUS 

(Hcst2  is  now  free  to  send  status  information  at  any  time. 
Solicitations  from  Hostl  are  NOT  necessary.  This  should  not  produce 
any  dangerous  race  conditions.  At  worst,  two  IS's  will  be  sent.) 

Hostl  (perhaps):  lAC  SB  STATUS  SEND  lAC  SE 

Host2  (the  following  stream  is  broken  Into  multiple  lines  only  for 
readability.  No  carriage  returns  are  impUed.): 

lAC  SB  STATUS  IS 

WILL  ECHO 

DO  SUPPRESS-GO-AHEAD 
WILL  STATUS 
DO  STATUS 
lAC  SE 

Explanation  of  Host2's  perceptions:  It  is  responsible  for  echoing 
back  the  data  characters  it  receives  over  tne  TELNET  connection; 
it  will  not  send  Go-Ahead  signals;  it  will  both  issue  and  request 
Status  information. 
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APPEND  E 

TELNET  TIMING  MARK  OPTION 

1C.  Command  name  and  code. 

TIMING-MARK  6 

20.  Command  meanings. 

20.1  lAC  WILL  TIMING-MARK.  The  sender  of  this  command  ASSURES  the  receiver 
of  this  command  that  it  is  inserted  in  the  data  stream  at  the  "appropriate 
place"  to  insure  synchronization  with  a  00  TIMING-MARK  transmitted  by  the 
receiver  of  this  command. 

20*2  lAC  W0N*T  TIMING-MARK.  The  sender  of  this  command  REFUSES  to  insure 
that  this  command  is  inserted  in  the  data  stream  at  the  "appropriate  place"  to 
insure  synchronization, 

20.3  lAC  DO  TIMING-MARK.  The  sender  of  this  command  REQUESTS  that  the 
receiver  of  this  command  return  a  WILL  TIMING-MARK  in  the  data  stream  at  the 
"appropriate  place"  as  defined  in  paragraph  11.4  below. 

20.4  lAC  DON'T  TIMING-I1ARK.  The  sender  of  this  command  notifies  the 
receiver  of  this  command  that  a  WILL  TIMING-MARK  (previously  transmitted  by 
the  receiver  of  this  command)  has  been  IGNORED. 

30.  Default. 

WON'T  TIMING-MARK.  DON'T  TIMING-MARK 

i.e..  No  explicit  attempt  is  made  to  s/nchronize  the  activities  at  the  two 
ends  of  the  TELNET  connection, 

40.  Motivation  for  the  option.  U  is  sometimes  useful  for  a  user  or 
process  at  one  end  of  a  YElneT  connection  to  be  sure  that  previously 
transmitted  data  has  been  completely  processed,  printed,  discarded,  or 
otherwise  disposed  of.  This  option  provides  a  mechanism  for  doing  this.  In 
addiiion,  even  if  the  option  request  (DO  TIMING-MARK)  is  refused  (by  WON'T 
TIMING-MARK)  the  requester  is  at  least  assured  that  the  refuser  has  received 
(if  not  processed)  all  previous  data. 

50.  Examples  of  option  application.  As  an  example  of  a  particular 
application,  imagine  a  iELNti  connection  between  a  physically  full  duplex 
terminal  and  a  "full  duplex"  serve**  system  which  permits  the  user  to  "type 
ahead"  while  the  server  is  processing  previous  user  input.  Suppose  that  both 
sides  have  agreed  to  Suppress  Go  Ahead  and  that  the  server  has  agreed  to 
provide  echoes.  The  server  now  discovers  a  command  which  it  cannot  parse, 
perhaps  because  of  a  user  typing  error.  It  would  like  to  threw  away  all  of 
the  user's  "type-ahead"  (since  failure  of  the  parsing  of  one  command  is  likely 
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to  lead  to  Incorrect  results  if  subsequent  coamands  are  executed),  send  the 
user  an  error  message,  and  resui&e  interpretatlou  of  commands  which  the  user 
typed  after  seeing  the  error  message.  If  the  user  were  local,  the  system 
would  be  able  to  discard  the  buffered  input;  but  Input  may  be  buffered  in 
the  user's  host  or  elsewhere.  Therefore,  the  server  might  send  a  DO  TIMING- 
MARK  and  hope  to  receive  a  WILL  TIMING-iiARK  from  the  user  at  the  “appropriate 
place “  in  the  data  stream.  The  “appropriate  place"  (in  absence  of  other 
information)  is  clearly  just  before  the  first  character  which  the  user  typed 
after  seeing  the  error  message.  That  is,  it  should  appear  that  the  timing 
nark  was  “printed"  on  the  user's  terminal  and  that,  in  response,  the  user 
typed  an  answering  timing  mark.  Next,  suppose  that  the  user  in  the  example 
above  realized  that  he  had  misspelled  a  ccomand,  realized  that  the  server 
would  send  a  DO  TIMING-MARK,  and  wanted  to  start  “typing  ahead"  again  without 
waiting  for  this  to  occur.  He  might  then  instruct  his  own  system  to  send  a 
WILL  TIMING-MARK  to  the  server  and  then  begin  "typing  ahead"  again.  (Imple- 
menters  should  remember  that  the  user's  own  system  must  remember  that  It 
sent  the  WILL  TIMING-MARK  so  as  to  discard  the  DO/DON'T  TIMING-MARK  when  it 
eventually  arrives.)  Thus,  In  this  case  the  "appropriate  place"  for  the 
insertion  of  the  WILL  TIMING-MARK  is  the  place  defined  by  the  user.  In  both 
of  the  examples  above,  it  is  the  responsibility  of  the  system  which  transmits 
the  DO  TIMING-MARK  to  discard  any  unwanted  characters;  the  WILL  TIMING-MARK 
only  provides  help  in  deciding  which  characters  are  "unwanted". 

6.0  Description  the  option.  Suppose  that  Process  A  of  Figure  2  wishes 
to  syn^ronlze  with  B.  The  DO  TIMING-MARK  Is  sent  from  A  to  B.  B  can  refuse 
by  replying  WON'T  TIMING-MARK,  or  agree  by  permitting  the  timing  mark  to 
flow  through  his  "outgoing"  buffer,  BUP2.  Then,  instead  of  delivering  it  to 
the  terminal,  B  will  enter  the  mark  into  his  "incoming"  buffer  BUFl,  to  flow 
through  toward  A.  When  the  mark  has  propagated  through  B's  incoming  buff'tr, 

B  returns  the  WILL  TIMING-MARK  over  the  TELNET  connection  to  A. 
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FIGURE  2.  Synchronization  of  processes. 

When  A  receives  the  WILL  TIMING-MARK,  he  knows  that  all  the  information  he 
sent  to  B  before  sending  the  timing  mark  been  delivered,  and  all  the  informa¬ 
tion  sent  from  B  to  A  before  turnaround  of  the  timing  mark  has  been  delivered. 
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70.  Three  typical  applications. 

70.1  Round«»tr1p  delay.  Measure  round-trip  delay  between  a  process  and  a 
terminal  or  another  process. 

70.2  Resvnchronization.  Resynchronizing  an  interaction  is  described  in 
paragraph  4  above.  A  is  a  process  interpreting  commands  forwarded  from  a 
terminal  by  B.  When  A  sees  an  illegal  command  it: 

a.  Sends  <carriage  return>,  <line  feed>,  <question  mark>. 

b.  Sends  DO  TIMING-MARK. 

c.  Sends  an  error  message. 

d.  Starts  reading  input  and  throwing  it  away  until  it  receives  a 
WILL  TIMING-MARK. 

e.  Resumes  interpretation  of  input. 

This  achieves  the  effect  of  flushing  all  “type  ahead"  after  the  erroneous 
commandi  up  to  the  point  when  the  user  actually  saw  the  question  mark, 

70.3  Dual  synchronization.  The  dual  of  paragraph  7.2.  The  terminal  user 
wants  to  throw  away  unwanted  output  from  A. 

a.  B  sends  DO  TIMING-MARK,  followed  by  some  new  cor.nand. 

b.  B  starts  reading  output  from  A  and  throwing  it  away  until  it 
receives  WILL  TIMING-MARK. 

c.  B  resumes  forwarding  A's  output  to  the  terminal. 

This  achieves  the  effect  of  flushing  all  output  from  A,  up  to  the  point  where 
A  saw  the  timing  mark,  but  not  output  generated  in  response  to  the  following 
command. 
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APPENDIX  F 

TELNET  EXTENDED  OPTIONS  -  LIST  OPTION 

10,  Command  name  and  code. 

EXTENDED-OPTIONS-LIST  (EXOPL)  255 

20.  Command  meanings. 

20.1  lAC  WILL  EXOPl.  The  sender  of  this  command  REQUESTS  permission  to 
begin  negotiating,  or  confirms  that  it  will  begin  negotiating,  TELNET  options 
which  are  on  the  "Extended  Options  List." 

20.2  lAC  W0N*T  EXOPL.  The  sender  of  this  command  REFUSES  to  negotiate,  or 
to  continue  negotf alTng ,  options  on  the  "Extended  Options  List." 

20.3  lAC  DO  EXOPL.  The  sender  of  this  command  REQUESTS  that  the  receiver 
of  this  command  begin  negotiating,  or  confirms  that  the  receiver  of  this 
command  is  expected  to  begin  negotiating,  TELNET  options  which  are  on  the 
"Extended  Options  List." 

20.4  I AC  DON'T  EXOPL.  The  sender  of  this  command  DEMANDS  that  the  receiver 
conduct  no  further  negotiation  of  options  on  the  "Extended  Options  List." 

20.5  lAC  SB  EXOPL  <subcommand>.  The  subcommand  contains  information 
required  for  the  negotiation  of  an  option  of  the  "Extended  Options  List."  The 
format  of  the  subcommand  is  discussed  in  paragraph  5  below. 

30.  Default. 

WON’T  EXOPL.  DON'T  EXOPL 

Negotiation  of  options  on  the  "Extended  Options  List"  is  not  permitted. 

40.  Motivation  for  the  option.  Eventually,  a  257th  TELNET  option  will  be 
needed.  This  option  win  extend  the  option  list  for  another  256  options  in  a 
manner  wnich  is  easy  to  implement.  The  option  is  proposed  now,  rather  than 
later  (probably  much  later),  in  order  to  reserve  the  option  nimiber  (255). 

50.  Description  of  the  option.  The  EXOPL  option  has  five  subcommand  codes: 
WILL,  WoN'f,  tX),  DoN*t,  and  They  have  exactly  the  same  meanings  as  the 
TELNET  coiTTiands  with  the  same  names,  and  are  used  in  exactly  the  same  way. 

For  consistency,  these  subcommand  codes  will  have  ♦^^he  same  values  as  the 
TELNET  command  codes  (250-254).  Thus,  the  format  for  negetiating  a  specific 
option  on  the  "Extended  Options  List"  (once  both  parties  have  agreed  to  use 
it)  is: 
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Once  both  sides  have  agreed  to  use  the  specific  option  specified  by  option 
code>,  subnegotiation  may  be  required.  In  this  case  the  format  to  be  used  is: 

lAC  SB  EXOPL  SB  <option  code>  <parameters>  SE  lAC  SE 


*  U.S.  COVtmateT  WIHTIHC  OTFICJi  1M4-70S-0*0:AMSS 


STANDARDS: 


X.25 


DEFENSE  COMMUNICATIONS  AGENCY 


DEFENSE  DATA  NETWORK 
)C25  HOST  INTERFACE 
SPECIFICATION 


DECEMBER  1983 


PREFARED  BY  BBN  COMMUNICATIONS  CORPORATION 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


ACKNOWLEDGEMENTS 


This  specification  was  prepared  by  BBN  Communications  Corporation 
under  contract  to  the  Defense  Data  Network  Program  Management 
Office  of  the  Defense  Communications  Agency. 

The  specification  has  been  reviewed  by  the  Defense  Communications 
Engineering  Center  for  accuracy  and  completeness.  The  draft  of 
this  specification  has  been  disseminated  to  industry  by  the 
National  Bureau  of  Standards  for  review  and  comments  which  have 
been  incorporated  in  the  final  specification.  This  specification 
has  been  approved  for  use  on  the  Defense  Data  Network  by  the  DoD 
Protocol  Standards  Steering  Group. 


Comments  on  this  specification  should  be  directed  to  the  Defense 
Communications  Agency,  ATTN;  Defense  Data  Network  Program 
Management  Office,  Code  6610,  Washington,  D.C.  20305 


ii- 


1*168 


MILITARY  STANDARDS:  X.25 


Table  of  Contents 


1  INTRODUCTION . 

1.1  Background . VI*:;:,* 

1.1.1  X.25  and  FIPS  100/Federal  Standard  1041 

1.1.2  X.25-to-X.25  and  X.25-to-1822 

Interoperability . 

1.2  Compliance . **  * 

1.2.1  Compliance  With  CCITT  X.25  and  FIPS 

lOO/Fed.  Std.  1041 . 

1.2.2  DTE  Compliance  With  This  Specification. 


2  INTERFACE  SPECIFICATION.... . 

2.1  Call  Establishment  Conventions . 

2.1.1  Addressing . 

2. 1.1.1  Address  Formats  and  Fields . 

2. 1.1. 1.1  Reserved . 

2. 1.1. 1.2  Flag . . . . 

2. 1.1. 1.3  DDN  Host  Identifier . 

2. 1.1. 1.4  Sub-Address . . . 

2. 1.1. 2  Supplying  Missing  Address  Information . 

2.1.2  DDN-Specific  Facilities.. . 

2.1 .2.1  Type  of  Service  Selection . 

2. 1.2. 2  Call  Precedence . 

2.1.3  Protocol  Identification . 

2.1.4  Logical  Channel  Assignment . 

2.2  Packet  Level  . . 

2.3  Link  Level  Procedures . 

2.3.1  Link  Level  Parameters  and  Options . 

2.3.2  Timer  T1  and  Parameter  . . 

2.3.3  Maximum  I  Frame  Size . 

2.4  Physical  Level  Specifications . 


5 

6 
6 
6 
7 
7 
7 
7 

7 

8 
8 
9 

10 

10 

11 

12 

12 

12 

13 

14 


3  BIBLIOGRAPHY 


16 


APPENDIX  A:  DDN  X.25  Implementation  Details 


A-1  Introduction . -  •  •  •  •  •I'l*!  *  ‘  * . 

A-2  Operational  Features  of  DDN  X.25  DCE  Releases . 

A-2.1  Initial  Feature  Support . 

A-2.2  Exception-Handling  Procedures . 

A-2.2.1  Non-Octet-Aligned  Data . 

A-2.2.2  RESTART  REQUEST  Packet . . . 

A-2.2.3  reset  REQUEST  Packet . 

A-2.2.4  CLEAR  REQUEST  Packet . 

A-2.3  Virtual  Circuit  Resource  Availability . . 


A-i 
A-1 
A-1 
A- 2 
A- 2 
A-2 
A-2 
A- 3 
A- 3 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


A-3  Detailed  Features  and  Facilities 

Specifications. . . . . 

A"*!.!  Additional  Cedes.  ^ j  . . 

A-3. 2  X.25  IP  Interoperability  Considerations . 

A-3. 3  The  DDN  Logical  Addressing  Facility . 

A-3. 3.1  Logical  Addresses . !**:*:il . I** 

A-3. 3. 2  Enabling  and  Disabling  Logical  Addresses.. 

A-4  Limitations  of  DDN  Basic  X.25  Service . 

A-5  Derivation  of  DDN  X.25  Addresses . 

APPENDIX  B:  DDN  Synchronous  Level  1  Specification.. 

B-1  Introduction . 

B-2  Supported  Interfaces . . . 

APPENDIX  C:  Federal  Information  Processing  Standard 
Publication  100 . 


MILITARY  STANDARDS:  X.25 


TABLES 


DON  X.25  Address  Fields . 

Derivation  of  Maximum  I  Frame  Size . . 

DDN  X.25  Physical  Signaling  Rates  and  Interfaces 

Additional  Packet  Level  Diagnostic  Codes . 

IP  Precedence  to  X.25  Precedence  Mapping . 

EIA  and  CCITT  Interchange  Circuits . 

Signal  Selection  by  CCITT  Interchange  Circuit 

Number . 

Typical  Level  1  Connection  Schemes.. . . 

Interface  Type  by  Service  Speed.... . 

RS-232-C  Interface . . . . . 

MIL-188-114  Interface  (and  equivalents) . . 

V.35  Interface . 


..  7 
.  14 
.  15 
A-4 
A-6 
B-3 

B-4 
B-5 
'  7 
B-8 
B-9 
B-10 


MILITARY  STANDARDS:  X.25 


1  INTRODUCTION 


This  report  specifies  the  attachment  of  an  X.25  host  to  the 
Defense  Data  Network  (DDN) .  In  particular,  this  report  describes 
specific  options  and  features  of  CCITT  Recommendation  X.25  (1980) 
and  Federal  Information  Processing  Standard  (PIPS)  100/Fedeial 
Standard  (Fed.  Std.)  1041  (July  1983)  required  of  a  host  X.25 
implementation  to  enable  that  host  to  communicate  with  a  DDN  X.25 
Interface  Message  Processor  CIMP-,  the  DDN  switching 

node).  This  report,  in  conjunction  with  vIPS  100/Fed.  Std. 
1041,  should  enable  DDN  host  site  managers  and  others  planning  to 
attach  a  host  by  means  of  X.25,  rather  than  the  1822  interface, 
to  determine,  first,  whether  or  not  the  X.25  implementation  of 
the  host  in  question  is  adequate  for  operation  with  DDN,  and, 
second,  what  options,  parameter  settings,  etc.  must  or  may  be 
selected  for  operation  with  DDN. 


This  report  assumes  that  the  reader  is  familiar  with  CCITT 
Recommendation  X.25  and  FIPS  100/Fed.  Std.  1041.  A  copy  of  FIPS 
100/Fed.  Std.  1041  is  attached  as  Appendix  C  of  this  report. 


In  this  document,  the  term  "Administration"  refers  to  the 
Defense  Communications  Agency  {DCA  Code  B610,  Washington,  D.  C. 
20305) . 


1.1  Background 

1.1.1  X.25  and  FIPS  100/Federal  Standard  1041 


The  CCITT  Recommendation  X.25  describes  the  interface 
between  host  computers  (data  terminal  equipment,  or  DTEs)  and 
data  circuit-terminating  equipment  (DCEs,  which 
communication  with  remote  hosts  over  computer  networks)  for  hosts 
operatinq  in  the  packet  mode  on  public  data  networks.  The 
Interface  standard  is  defined  as  three  independent  architectural 
levels,  following  the  Open  Systems  Interconnection  (OSI) 
.-'ference  Model.  The  three  levels  are: 


Level  1:  The  PHYSICAL  level  of  the  connection.  The 

physical,  electrical,  functional,  and 

procedural  characteristics  to  activate, 

•  As  used  in  this  report,  "1822  interface"  refers  to  the 
interface  specified  in  Bolt  Beranek  and  Newman  Inc.  (BBN)  Report 
No.  1822,  "Specification  for  the  Interconnection  of  a  Host  and  an 
IMP,"  revision  of  December  1981. 
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maintain,  and  deactivate  the  physical  link 
between  the  DTE  and  the  DCE. 

Level  2:  The  LINK  level  of  the  connection.  The  link 
access  procedure  for  data  interchange  across 
the  link  between  the  DTE  and  the  DCE. 

Level  3:  The  PACKET  level  of  the  connection.  The 
packet  format  and  control  procedures  for  the 
exchange  of  packets  containing  control 
information  and  user  data  between  the  DTE  and 
the  DCE,  and  between  the  DTE  and  a  remote 
DTE. 


CCITT  Recommendation  X.25  contains 
implementation  choices.  FIPS  100/Fed.  Std.  1041,  which  specifies 
Ue  general  use  of  X.25  for  the  Federal  Government,  defines  some 
of  the  choices  left  open  in  X.25.  This  document  describes  the 
X.25  interface  to  a  particular  network,  DDN.  Thus  in  several 
areas  where  X.25  allows  a  choice,  a  single  choice  appropriate  for 
DDN  is  specified;  in  areas  which  X.25  leaves  unspecified, 
addressing  in  particular,  conventions  are  specified  that  are 
consistent  with  the  overall  architecture  of  DDN  and  the 
interoperability  goals  described  below.  The  effect  of  this 
approach  is  to  make  DDN  service  available  to  hosts  in  a  way  that 
requires  no  changes  to  a  host  DTE  iroplemwtation  that  is 
compliant  with  FIPS  100/Fed.  Std.  1041  and  CCITT  Recommendation 
X.25.  By  implementing  extensions  described  in  this 
specification,  a  host  will  be  able  to  take  advantage  of 
additional  DDN  features  required  in  military  networks,  such  as 
precedence  and  logical  addressing. 


The  reader  is  referred  to  CCITT  Recommendation  X.25  and  to 
FIPS  100/Fed.  Std.  1041  for  detailed  information  not  provided  in 
the  body  of  this  document. 


1.1.2  X.25-to-X.25  and  X.25-to-1822  Interoperability 

A  key  goal  of  the  DDK  X.25  implementation  is 
i nr op# fab i 1 i ty  among  all  DDN  subscribers.  That  is,  effective 
communication  should  be  possible,  not  only  between  subscribers 
attached  to  the  DDN  using  Identical  vendor-supplied  X.25 
implementations,  but  between  subscribers  using  different  X.25 
implementations,  and  between  a  subscriber  using  an  X.25  interface 
to  the  DDN  and  a  subscriber  using  an  1822  interface  to  the  DDN. 
Achieving  this  goal  of  Interoperability  requires  that  all  DDN 
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X.25  subscribers  conform  to  this  interface  specification  and 
implement  the  DoD  standard  higher  level  protocols.  True 
interoperability  among  DDN  hosts  requires r  in  particular r 
implementation  of  the  noD  standard  protocols  TCP  (Transmission 
Control  Protocol)  and  IP  (Internet  Protocol),  as  well  as  the 
higher-level  protocols  which  implement  DDN  standard  services, 
when  such  services  are  provided  by  the  host;  the  Telnet  Protocol 
for  character-oriented  terminal  support,  the 
Protocol  (FTP)  for  file  movement  between  hosts,  and  the  Simple 
Mail  Transfer  Protocol  (SMTP)  for  communication  between 
electronic  mail  service  hosts. 

The  DDN  X.25  DCE  offers  two  types  of  service  to  X.25  DTEs: 

1.  DDN  Standard  X.25  Service,  which,  when  used  in 
conjunction  with  DoD  standard  protocols,  provides 
interoperable  communication  between  an  X.25  DTE 
and  other  DDN  hosts  that  also  implement  the  DoD 
standard  protocols,  whether  they  are  connected  to 
DDN  via  the  1822  interface  or  via  the  X.25 
interface; 

and 

2.  DDN  Basic  X.25  Service,  which  provides 
communication  only  between  an  X.25  DTE  and  other 
DDN  X.25  DTEs  implementing  compatible  higher-level 
protocols. 

Section  2.1,2.!  of  this  report  describes  the  conventions  to 
be  used  by  a  DTE  to  specify  the  type  of  service  desired  for  each 
X.25  virtual  call.  All  DDN  X.25  DTEs  will  be  required  to  develop 
and  initiate  a  plan  to  use  the  DoD  standard  protocol  architecture 
and  DDN  standard  X.25  service. 

Use  of  DDN  basic  X.25  service  imposes  some  restrictions  on 
the  nature  of  the  network  communications  service  that  a  host  can 
obtain.  These  restrictions  are  discussed  in  Appendix  A,  Section 
A-4. 
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1.2  Compliance 

1.2.1  Compliance  With  CCITT  X.25  and  FIPS  100/Fed.  Std.  1041 


The  DDN  X.25  Interface  Specification  is  compliant  with  CCITT 
Recommendation  X.25  and  FIPS  100/Fed.  Std.  1041.  The  DDN  ^.25 
DCE  supports  all  facilities  specified  as  E  (essential)  by  fips 
100/Fed.  Std.  1041  r  and  facilities  specified  as  A 
(additional).  The  additional  facilities  not  supported  are; 


(i)  datagrams  and  associated  facilitiesr 
and 

(ii)  bilateral  closed  user  groups. 


In  that  FIPS  100/Fed.  Std.  1041  describes  features  for  a 
DCEr  DON  X.25  DTEs  may  support  any  or  all  facilities  specified  as 
either  E  or  A  by  FIPS  100/Fed  Std.  1041.  However^  DDN  X.25  DTEs 
must  not  use  the  facilities  identified  above  that  are  not 
supported  by  the  DDN  X.25  DCE. 


1.2.2  DTE  Compliance  With  This  Specification 

This  document  specifies  several  areas  in  which  the  DON  X.25 
DCE  is  capable  of  operating  in  several  modes.  For  exampler 
Section  2.4  lists  a  number  of  signaling  rates  supported  by  the 
DCE.  In  such  cases,  a  DDN  X.25  DTE  must  implement  at  least  one 
of  the  options  listed  (or  the  set  of  options  required  of  a  DTE  by 
FIPS  100/Fed.  Std.  1041)  but  need  not  implement  all  of  the 
options  listed  (unless  required  by  FIPS  100/Fed.  Std.  1041). 
Determining  the  adequacy  of  the  options  supported  by  a  DTE  vendor 
for  meeting  a  DDN  subscriber's  requirements  is  the  responsibility 
of  the  subscriber. 

In  addition  to  the  CCITT  X.25  and  FIPS  100/Fed.  Std.  1041 
requirements  described  in  Section  1.2.1  above,  DDN  X.25  DTEs  may 
wish  to  take  advantage  of  additional  OHM-specific  features  that 
are  compatible  extensions  to  the  public  standards. 
Implementation  of  a  DDN-speclfic  feature  by  a  host  is  required 
only  if  the  host  wishes  to  take  advantage  of  the  service  or 
information  provided  by  the  feature.  For  example,  a  host  that 
wishes  to  establish  calls  only  at  the  default  precedence  level 
assigned  to  it  need  not  implement  the  precedence  facility 
described  in  Section  2. 1.2. 2.  However,  a  host  that  wishes  to 
have  flexibility  in  the  precedence  of  the  calls  it  establishes 
mast  implement  this  facility. 
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Any  deficiencies  with  respect  to  this  specification  in  a 
vendor-supplied  X.25  DTE  implementation  contemplated  for  use  with 
the  DDN  X.25  DCE  should  be  rectified  so  as  to  attain  compliance 
with  this  specification.  Proper  operation  with  DDN  of  an  X.25 
DTE  that  is  not  compliant  with  this  specification  cannot  be 
guaranteed  and  should  not  be  attempted.  To  this  end,  a  test 
program  is  available  through  the  Administration. 
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I  INTERFACE  SPECIFICATION 

2.1  Call  Establishment  Conventions 

This  section  specifies  DDN  X.25  call  establishment 
conventions. 


2.1.1  Addressing 

DDN  addresses  are  assigned  to  subscriber  DTEs  by  the 
Administration.  Two  basic  forms  of  address  are  provide; 
physical  addresses r  which  correspond  to  the  node  number  and  DCE 
port  number  of  the  node  to  which  the  DTE  is  connected r  and 
logical  addresses#  which  are  mapped  transparently  by  DCE  software 
into  a  corresponding  physical  network  address.  Each  DTE  is 
assigned  one  physical  address#  and  may  be  assigned  one  or  core 
logical  addresses.  All  DDN  addresses  are  either  twelve  or 
fourteen  BCD  (binary-coded  decimal)  digits  in  length.  A  calling 
DTE  need  not  determine  whether  a  given  address  is  a  physical  or 
logical  address#  in  order  to  establish  a  call  to  that  address. 


2.1.1.1  Address  Formats  and  Fields 

DDN  addresses  have  the  following  format: 

ZZZZ  F  DDDODDD  (SS) 

The  various  fields  of  the  address  are  presented  in  Table  2.1  and 
are  explained  below. 

Length 


Field 

Meaning 

(BCD 

digits) 

ZZZZ 

Reserved 

(must  be  zero) 

4 

F 

Flag 

1 

DDDDDOD 

DDN  Host 

Identifier 

7 

(SS) 

Sub-address  (optional)  0 

or  2 

TOTAL  12  or  14 


Table  2.1  DDN  X.25  Address  Fields 
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DTE  implementors  are  cautioned  that  use  of  this  mechanism  In 
accepting  calls  to  a  DTE*s  logical  address  (See  Appendix  A, 
Section  A-3.3)  can  result  in  confusion  on  the  part  of  the  calling 
DTE  and  Is  not  advised. 


2.1.2  DDN-Speclflc  Facilities 

Two  DDN-speciflc  features  are  requested  by  means  of 
"private"  or  non-CCITT  facilities  In  CALL  REQUEST  and  CALL 
ACCEPTED  packets.  If  either  or  both  of  these  facilities  are 
requested  In  a  CALL  REQUEST  or  CALL  ACCEPTED  packet,  they  must 
follow  all  CCITT  X.25  facilities  and  must  be  preceded  by  a  single 
facility  marker,  two  octets  of  zero. 


2. 1.2.1  Type  of  Service  Selection 

The  DON  X.25  provides  two  types  of  service,  DDN  basic  X.25 
service  and  DON  standard  X.25  service.  DDN  standard  X.25  service 
provides  only  local  DTE  to  local  DCE  support  of  the  X.25 
connection.  Data  Is  carried  via  the  network  to  Its  destination 
(using  protocols  Internal  to  the  network),  where  It  Is  delivered 
using  the  access  protocol  of  the  destination  host  (l*e.,  either 
1822  or  DON  standard  X.25  service).  This  access  method  is 
oriented  towards  DON  X.25  hosts  using  the  OoD  standard  TCP/IP 
higher  level  protocols.  No  X.25  procedures  change  when  using  DON 
standard  X.25  service;  however,  the  significance  of  the 
procedures  changes  (see  Appendix  A,  Section  A-3.2).  There  Is  no 
end-to-end  X. 25-level  acknowledgement  or  guarantee  of  delivery  of 
data  packets  with  DON  standard  X.25  service;  reliability  of  DON 
standard  X.25  service  Is  provided  Instead  by  the  use  of  a 
reliable  transport  protocol. 

DDN  basic  X.25  service  provides  end-to-end  call  management 
with  significance  as  described  In  CCITT  Recommendation  X.25  and 
FIPS  100/Fed.  Std.  1041.  This  access  method  Is  oriented  towards 
hosts  that  have  existing  higher  level  protocol  implementations 
that  require  reliable  packet  delivery  at  the  network  level. 

Selection  of  DDN  standard  or  DDN  basic  X.25  service  mus:  be 
made  on  a  call-by-call  basis  by  the  DDN  X.25  DTE  at  the  time  of 
call  setup.  To  specify  DON  standard  X.25  service,  a  DTE  must 
Include  In  the  CALL  REQUEST  packet  a  facility  two  octets  long, 
coded  as  follows: 


00000100  00000001 
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2.1. I. 1.1  Reserved 

The  Reserved  field  corresponds  to  the  DNIC  field  generally 
used  in  public  data  networks.  Pending  assignment  of  a  DDW  DNic, 
this  field  must  be  zero. 


2. 1.1. 1.2  Flag 

The  Flag  field  is  used  to  differentiate  physical  and  logical 
addressing.  The  value  zero  indicates  physical  addressing,  while 
the  value  one  indicates  logical  addressj^ng.  A  value  of 
used  in  the  setup  of  calls  to  enable  and  disable  logical 
addresses;  see  Appendix  A,  Section  A-3.3.1. 


2. 1.1. 1.3  DDN  Host  Identifier 

The  DDN  Host  Identifier  is 
logical  or  physical,  assigned 
Administration. 


a  seven^digit  address,  either 
to  a  subscriber  DTE  by  the  DDN 


2. 1.1. 1.4  Sub-Address 

The  Sub-Address  may  be  used  by  a  DTE  for  any  purpose.  It  is 
carried  across  the  network  without  modification.  Its  presence  is 
optional. 


2. 1.1. 2  Supplying  Missing  Address  Information 

The  DDN  X.25  OCE  Incorporate,  a  oechanisis  to  *“PPly 
"®l..inQ’'  address  Inforoation  in  CALL  REQUEST  and  CALL  ACCEPTED 
packets  received  fron  an  attached  DTE.  This  oechaniSR  is  useful 
in  uTE  software  testin9  and  physical  address  deterwination. 


If  a  DTE  sends  a  CALL  REQUEST  packet  with  no  calling  address 
field,  the  local  DCE  will  insert  the  physical  calling  DDR  Host 
Identifier  with  no  subaddress  field.  If  a  DTE  sends  a  CALL 
REQUEST  or  CALL  ACCEPTED  packet  with  either  or  both  calling  or 
called  addresses  that  contain  F  •  *eto  and  DDDDDDD  ‘I** 
local  DCE  will  replace  the  DON  Host  Identifier  field  (DDDODOD) 
with  the  physical  address  of  the  DTE. 
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If  this  facility  is  not  specified,  DDN  basic  X.2S  service  will  be 
provided. 


2 .1.2 .2  Call  Prtcedenct 

Tht  prtcedence  of  a  call  ia  naootiated  by  an  X.25  DTE  by 
mtana  of  a  facility  two  octets  long,  coded  as: 

OOOQIOOO  OOOOOOXX 


where  XX  is  the  precedence,  from  0  (lowest  precedence)  to  3 
(highest  precedence).  If  this  facility  is  not  used,  the  call 
will  be  established  at  the  subscriber's  default  precedence. 


A  DTE  is  not  permitted  to  establish  a  call  at  a  precedence 
level  higher  than  that  authorised  for  that  by  the 

Administration.  An  attempt  to  do  so  will  result  in  tne  DDN  X.25 
DCE  returning  to  the  DTE  a  CLEAR  INDICATION  packet  with  clearing 
cause  00001001,  "Out  of  order,"  with  diagnostic  code  194, 
"Reguested  precedence  too  high." 

Calls  of  a  lower  precedence  may  be  cleared  by  a  DCE  if  ^E 
or  other  network  resources  are  required,  or  if  access  to  we 
local  or  remote  DTE  is  required  (for  a  call  of 
precedence).  In  this  event,  a  CLEAR  INDICATION  packet  will  be 
sent  with  the  clearing  cause  00000101,  "Network  congestion,  and 
with  a  diagnostic  code  specifying  the  reason  for 
The  diagnostic  codes  employed  for  this 
due  to  higher  precedence  call  at  local  0«, 
due  to  higher  precedence  call  at  remote  DCE.  *!) 

attempt  to  establish  a  call  may  be  unsuccessful  if  network 
resources  are  engaged  in  calls  of  higher  priority  that 

r.qu«.t  «}.  In  thia  c.a.,  a  CLEAR  INDICATION  pack. t  will  b.  8.nt 
with  the  clearing  cause  00001001,  "Out  of  order,  and  with  either 
diagnostic  code  192  or  193,  as  appropriate. 


The  diagnostic  codes  described  in  tht  preceding  paragraphs 
are  DDN-specific  diagnostic  codes;  additional  information  about 
these  codes  may  be  found  in  Appendix  A,  Section  .V3.1. 
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2.1.3  Protocol  Identification 

X.25  DTEs  employing  the  DoD  standard  TCP/IP  protocol 
architecture  must  Indicate  this  by  means  of  the 
field  of  the  CALL  REQUEST  packet.  The  first  octet  of  this  field 
must  be  set  to  11001100  to  Identify  the  DoD  standard  protocol 

architecture. 

Indication  of  the  use  of  the  DoD 
architecture  Is  Independent  of  the  selection  of  DDN  «twdard  or 
DDN  basic  X.25  service  by  means  of  the  facility  specified  In 
Section  2. 1.2.1  above.  Thereforsr  a 

standard  protocol  architecture  and  using  DON  stwdard  x.25 
service  must  Include  both  the  DDN  standard 

and  the  call  user  data  DoD  standard  protocol  Identification  in 
Its  CALL  REQUEST  packet. 

A  DTE  using  a  protocol  architecture  other  than  the  standard 
DoD  protocol  architecture  Is  free  to 
protocol  Identification  recognised  by  the  DTEs  with 
wishes  to  communicate.  Identification  of  protocol  architectures 
other  than  the  DoD  standard  architecture  Is  not  standardised  or 
enforced  by  the  Administration.  Subscribers  are  cautioned, 
therefore,  that  conflicts  among  various  vendor-assigned  protocol 
Identifications  may  arise. 


2.1.4  Logical  Channel  Assignment 

The  assignment  of  logical  channels  by 
follows  the  requirements  and  guidelines 

1041  and  Annex  A  of  CCITT  X.2$.  within  the  guidelines  of  CClTt 
X.25  Annex  A,  the  range  of  logical  channel  numbers  assigned  to 
permanent  virtual  circuits,  incoming,  two-way,  and  outgoing 
virtual  calls  for  DON  OCEs  Is  configured  for  each  DTE  attached  to 
a  DCE  by  the  Administration. 


DDN  x.25  DTEs  must  follow  the  logical  channel  selection 
requirements  of  FIPS  100/Fed.  Std.  1041. 

The  number  of  logical  channels  available  to  a  DTE  is 
dependent  upon  the  configuration  of  the  DCS  to  which  the  D*E  is 
attached,  and  upon  the  dynamic  requirements  placed  upon  other 
DCEs  that  share  the  same  DON  packet  switching  node. 
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2.2  Packet  Level  Procedures 


DDN  X.25  packet  level  procedures  are  as 
100/Fed.  Std.  1041  and  CCITT  X.25.  The  following  additional 

Information  Is  provided: 


1.  The  maximum  window  size  that  may  be  negotiated  Is 
seven . 

2.  Modulo  128  packet  level  sequence  numbering  Is  not 
supported. 

3.  Maximum  packet  sizes  of  16#  32#  64#  128#  256#  512# 
and  1024  octets  may  be  negotiated. 

4.  The  DDN  X.25  DCE  uses  additional  packet  Itvel 
diagnostic  codes#  specified  In  Appendix  A#  Table 
A-1.  DON  X.25  DTEs  may#  but  are  not  required  to# 
make  use  of  the  information  conveyed  by  these 
codes. 


5. 


th.  Qu.lifi.r  bit  (Q-bit)  t.  pass.d  tran«p«t.ntly 
by  th.  BON  X.25  BCE  in  BBN  bMie  X.25  s.rvic.. 
OTE.  o.tna  BBN  b.iic  X.25  ..rvic.  My  uM 
bit  in  any  way  that  Is  consistent  with  FIPS 
100/Fed.  Std.  1041. 


6.  The  DOM  X.25  DCE  implements  the  ^Ufoostic 

It  Is  sent  under  conditions  specified  in  Annex  D 
of  CCITT  X.25.  The  DTE  Is  not  required  to  act  on 
the  information  provided  In  diagnostic  packets. 


7.  DTEs  using  DOM  standard  X.25  service  must  restrict 
the  maximum  number  of  daUl  bits 
packet  sequence  to  be  no  more  than  80 5o.  this 
.nsur.s  th.t  th.  d.ta  fro®  .  p.cX.t  s.qu.nc. 
trMMltttd  by  X.25  host  will  fit  within  th. 
aaxisu®  H22  n.ss.9.  l.ngth  liait  upon  d.liv.ry  to 
an  1622  host.  This  r.striction  is  n.cessaty  as 
«xistin9  1822  host  implM.ntations  st.  not  tt- 
quittd  to  acc.pt  B.ssaq.f  lono.r  th.tn  8063  bits. 


♦  oTEa  usina  I®N  standard  x.25  saivic.  will  q.n.rally  b. 
transBittinq  Int.rn.t  Protocol  dataqraas.  th.  l.nqth  of  which,  by 
convantion,  do.s  not  approach  this  liBit.  ddS 
protocol  oth.t  than  th.  Int.rn.t  Protocol  ii  us.d  with  BBN 
standard  X.25  s.rvtc.,  this  is  a  technical 

hav.  no  practical  l»pact  upon  th.  d.sJqn  of  BTl  softwart.  S*. 
Appendix  A,  Saction  A-3.2. 
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DDN  X.25  DTE«  conntcting  to  DDN  ttacouqh  an  X.25 
Intatntt  Ptivata  Lina  Intarfaca  (IPLI)  nuat  taduca 
tha  naxlaua  complata  packat  aaquanca  lanqth  by  an 
additional  256  bita  to  allow  for  IPLI  ovarhaad. 


2.3  Link  Laval  Procaducat 


DDN  X.25  link  laval  ptocadurat  ate 
100/Fad.  Std.  1041  and  CCITT  X.25. 
additional  infornation. 


as  specified  by  FIPS 
This  section  peasants 


2.3.1  Link  Laval  Pacamaters  and  Options 

1.  Tha  dafai'lt  value  of  f,  tha  BasUiw  «« 

stqutntialXy  nu*btctd  I  friftts  thtt  tht  OCE  will 
havt  outstanding  (unacknowltd^td)  at  any  9 Ivan 

tisM,  is  seven.  A  DON  X.25  DCS  eay  be  confiqutad 
on  a  par-DTE  basis  to  provide  optional  values  of  X 
fro9  ona  to  tlx. 

2a  Tha  dafault  vaiua  of  HE,  tha  »axl»u»  nu»bar  of 

ttansnlsslont  and  ratranasissiona  of  a  fra»a 
foXloifln9  tha  axpiration  of  tha  TX  tlmarp  la 

tvantve  Tht a  vaXua  can  ba  chan9ad  to  any  vaXua 

fro«  ona  to  200  aa  a  DCE  conf juration  para»fltac 
on  a  par-DTE  baa la e 

3.  Tha  optionaX  32-blt  rCS  la  not  auppoctad. 


2.3.2  Timar  TX  and  Par»atar  T2 

Tha  period  of  tha  tiaar  TX  uaad  by  tha  OD» 
aaauaptiona  about  tha  procaaain9  apaad  of  tha  DTE.  Tha  OCE 
aaauaaa  that  paraaatar  T2s  tha  raaponaa  Xatancy  of  tha  DTE  to  a 
frasa  froo  tha  DCE,  ia  no  graatas  than  1/2  aacond.  Likaviaa,  tha 
XE  cuaranttaa  that  its  paraaatar  T2,  tha  Xatensy  In  raapondina 
to  frapaa  Croa  tha  DTE,  ia  1/2  aacond  for  uiqnMlinq  rataa  of 

19.2  Eb/a  or  alowar,  and  1/4  aacond  tor  faatar  links. 

A  lower  bound  for  tiaar  TX  aay  ba  coaputad  to  ba  4X  ♦  T2, 
based  on  tha  aaauaptions  that: 

•  tht  link  propagation  tiaa  ia  nagligiblt. 
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*  the  worst-case  frame  transmission  time  is  X, 

timer  T1  is  started  when  a  frame  is  scheduled  for 
output  r 

*  each  frame  is  scheduled  just  as  transmission  of 
the  previous  frame  starts r 

*  frames  are  not  abortedr  and 

*  each  frame  and  its  predecessor  are  of  maximum 
length  N1  -  8248  bits  (see  Section  2.3.3  below). 

As  an  example,  for  a  signaling  rate  of  9.6 
yields  X  •  .86  sec.  If  T2  is  .5  sec.,  the  total  time  for  the  DTE 

to  respond  in  the  worst  case  should  be  3.9  seconds.  In  factr  the 

DCE  uses  a  T1  timet  value  of  4  seconds  for  a  link  speed  of  9.6 
Kb/s. 

In  no  case  does  the  DCE  use  a  value  for  T1  smaller  than  3 
seconds.  This  means  that,  for  faster  links,  . 
parameter  may  be  lengthened  because  the  X  term  in 
formula  is  smaller.  For  lin^s  of  19.2  Kb/s  ^ 

expected  to  satisfy  latency  requirements  that  allow  the  DCE  to 
use  the  formula  4X  +  T2  (DTE)  <  3  seconds  «  T1  (DCE) . 

The  DTE  may  choose  any  value  for 

the  DCE*s  T2  parameter  values.  The  value  the 

may  always  be  set  longer  than  the  formula  indicates,  k! 

result  that  recovery  from  certain  types  of  link  errors 
•lower.  However,  the  DCE*8  parameter  T2  cannot  be  educed,  so 
the  formula  should  be  viewed  as  yielding  a  lower  bound  on  the 
DTE* 8  T1  timer. 


2.3.3  Maximum  I  Frame  Size 

The  maximuB  nuaber  HI  of  bits  in  «n  I  ®248. 
accommodating  a  data  packet  with  up  to  1024  data  octets.  The 
derivation  of  this  number  is  shown  in  Table  2.2. 

DTEs  using  DDN  standard  X.25  service  roust  observe  the 
restriction  on  the  number  of  data  bits  in  a  complete  packet 
sequence  given  in  Section  2.2  above. 
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Field  Name 


X.25  No.  of 
Level  Bits 


Address  2 
Control  2 
General  Format  Identifier  3 
Logical  Channel  Number  3 
Packet  Type  3 
User  Data  3 
Frame  Check  Sequence  2 


TOTAL 


Table  2.2  Derivation  of  Maximum 


8 

8 

4 

12 

8 

8192  (max) 
16 

8248  (max) 


I  Frame  Size 


2.4  Physical  Level  Specifications 

The  DDN  X.25  ohysical  level  specification  is  in  conformance 
with  FIPS  100/Fed.  Std.  1041  and  CCITT  X.25.  This  section 
presents  additional  information. 

A  DDN  X.25  DTE  may  either  be  collocated  with  its  DCE  or  may 
be  connected  to  it  via  an  access  line.  In  all  cases  the  DTE 
presents  a  physical  DTE  interface;  the  DON  will  supply  the 
matching  DCE  interface.  DDN  X.25  service  offers  four  physical 
level  interfaces:  RS-232-C  (CCITT  V. 28) ,  RS-449,  both  balanced 
and  unbalanced  (CCITT  V.ll  and  V.IO,  respectively;  also  MIL-188- 
114  balanced  and  unbalanced) >  and  CCITT  V.35.  Appendix  B  ot  this 
document  describes  in  detail  the  choices  of  physical  interface 
available  to  the  DDN  subscriber  and  the  specifications  for  each 
type  of  interface.  Table  2.3#  below#  summarizes  the  physical 
interfaces  available  at  each  data  rate  supported  by  the  DDN  X.zS 
DCE#  and  indicates  which  interfaces  are  recommended  at  each 
signaling  rate. 

A  DDN  X.25  DTE  may  implement  any  or  all  of  the  signaling 
rates  shown.  At  each  signaling  rate  implemented#  the  DTE  must 
offer  at  least  one  of  the  physical  interface  options  listed  as 
"R"  (recommended)  or  "A"  (available)  for  that  rate  in  Table  2.3. 
Implementors  are  encouraged  to  offer  the  widest  variety  of 
signaling  rates  and  physical  interfaces  practical  to  maximize 
the  ease  of  use  of  their  equipment  in  DDN. 
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Physical 

Interface 


Signaling  Rate  in  Kb/s 

1.2  2.4  4.8  9.6  14.4  48  50  56  64  100 


RS-232-C 


R  R  R  R  R 


RS-449  unbal.  A  A 

(and  equiv.) 

RS-449  balanced  A  A 

(and  equiv.) 

CCITT  V.35  -  - 


A  A 

A  A 


A 


A  A  A  A 

R  A  R  R 


R 

A 


Legend 


R  •  Recommended 
A  ■  Available 
-  ■  Not  available 


(Taken  from  Appendix  B,  Table  B-4 
Table  2.3  DON  X.25  Physical  Signaling  Rates  and  Interfaces 
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APPENDIX  A:  DDN  X.25  Implementation  Details 


A-1  Introduction 

This  Appendix  serves  three  purposes.  Pifst,  it  provides 
information  concerning  the  planned  evolution 
capabilities.  Second,  it  provides  information  on  the  ua®  ” 
certain  DDN  X.25  features  and  facilities  at  a  greater 
detail  than  is  appropriate  for  inclusion  in  the  body  of  the  DON 
X,2S  Interface  Specification.  Specifications  for  the  ^ 

X.2S  features  and  facilities  given  in  this  Appendix  are  mnnaaCQEi 
on  the  part  of  DDN  X.25  DTEs  that  wish  to  make  use  of  these 
features  and  facilities.  Finally,  this  Appendix  presents  a 
H<«rnga<f>n  of  the  limitations  on  the  use  of  DDN  services  that 
will  be  encountered  by  hosts  using  only  DDN  basic  X.25  service. 


A-2  Operational  Features  of  DDN  X.25  DCE  Releases 

The  capabilities  of  the  DON  X.25  DCE  will  evolve  o^et  time 
from  an  initial  set  of  capabilities  to  the 
this  DON  X.25  Interface  Specification. 

release-dependent  features  of  the  DDN  X.25  DCE.  Implementors 
should  note  that  not  all  optional  facilities  of  the  specification 
will  initially  be  available  for  use  by  DTEs. 


Releases  of  new  DCE  capabilities  will  be  com^tible  J|ith  Ote 
hardware  and  software  Implementations  that  meet  the  full  DDN  X.25 
Interface  Specification. 


A-2.1  Initial  Feature  Support 

The  initial  releaie  of  the  DDN  X.25  DCE  will  lup^rt  flow 
control  parameter  negotiation  and  fast  select.  In  addition^  the 
DDN  X.25  DCE  may  be  configured  by  the  DDN  Administration  to 
provide  non-standard  default  window  and  packet  sizes  as  described 
in  CCirr  x.25  Sections  7.1.2  and  7,2.1.  The  call  precedence  and 
type  of  service  selection  facilities  will  be  accepted#  but  not 
acted  upon#  by  the  network.  Only  DDN  basic  X. 25  service  will 
supported.  Planned  future  DCE  releases  .f^PPort 

facilities  specified  in  FIPS  100/Federal  Standard  1041  with 
exception  of  those  "additional"  facilities  that  are  listed 
Section  i.2.1  of  this  document. 


be 

all 

the 

in 
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A  detailed  schedule  of  DDN  X,25  DCE  releases  and  the 
capabilities  of  each  release  will  be  supplied  in  a  separate 
document. 


A-2.2  Exception-Handling  Procedures 

Certain  of  the  exception-  or  error-handling  procedures  of 
the  initial  release  of  the  DDN  X.25  DCE  differ  in  '’•tail  fro®  the 
procedures  specified  in  FIPS  100/Pederal  Standard 
differences  are  described  below.  A  later  release  of  the  DDN  X.25 
DCE  will  bring  these  procedures  into  conformance.  In  the 
interim#  the  variances  in  these  procedures  will  not  preclude 
satisfactory  operation  between  the  DCE  and  a  DTE#  provided  the 
DTE  operates  in  accordance  with  FIPS  100/Federal  Standard  1041. 


A-2.2.1  Non-Octet- Aligned  Data 

Data  packets  received  by  the  DDN  X.25  DCE  that  are  not 
aligned  on  an  octet  boundary  are  discarded  at  the  link  Ijvel- 
They  are  not  passed  to  the  DCE  packet  level#  and  no  packet  level 
diagnostic  code  is  returned  to  the  DTE. 


A-2.2. 2  F.ESTART  REQUEST  Packet 

The  DON  X.25  DCE  will  not  discard#  but  will  instead  act 
upon#  a  RESTART  REQUEST  packet  that 

(i)  is  too  long  (unless  it  exceeds  the  maximum  frame 
size  for  the  link  level)# 

or 

(ii)  contains  a  non-zero  cause  field. 


A-2.2 .3  RESET  REQUEST  Packet 

The  DDN  X.25  DCE  will  not  discard#  but  will  instead  act 
upon#  a  RESET  REQUEST  packet  that  contains  a  non-zero  reset  cause 
field. 
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A~2.2.4  CLEAR  REQUEST  PacKet 

The  DON  X.25  DCE  will  not  discard,  but  will  instead  act 
upon,  a  CLEAR  REQUEST  packet  that  contains  a  non-zero  clearing 
cause  field. 


A-2.3  Virtual  Circuit  Resource  Availability 

In  its  current  implementation#  the  DDN  X.25  packet  switching 
node  is  capable  of  supporting  a  minimum  of  one  hundred 
simultaneous  virtual  circuits.  As  was 

2.1.4#  resources  of  the  node  are  shared  dynamically  among  the 
DCEs  attached  to  the  node.  Therefore#  no  explicit  guarantees  are 
made  of  the  number  of  simultaneous  virtual  circuits  that  jan  be 
made  by  a  single  DTE.  Depending  upon  the  configuration  of  the 
node#  the  number  of  simultaneous  circuits  supported  by  the  node 
can  be  significantly  greater  than  one  hundred. 


A-3  Detailed  Features  and  Facilities  Specifications 


Thi I  section  provides 
descriptions  of  use  for  certain 


detailed  specifications  and 
DDN  X.25  features  and  facilities. 


A-3.1  Additional  Diagnostic  Codes 

The  DDN  X.25  DCE  is  capable  of  providing  additional 

information  to  DTEs  in  RESTART# 

DIAGNOSTIC  packets  by  means  of  diagnostic  codes  that  are 

extensions  to  the  set  of  diagnostic  codes  given  in  Annex  E  of 

CCITT  Recommendation  X.25.  These  codes  are  taken  from  ^e  of 

codes  "reserved  for  network  specific  diagnostic  information#  and 
are  thus  not  in  conflict  with  code  assignments  made  in  Annex  E. 
The  values  of  these  codes#  and  their  meanings#  are  given  in  Table 
A-1  below. 
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Codt 

Value 

128 

130 

131 

132 

133 

134 

136 

137 

138 

139 

140 


Meaning 


IMP  la  unavailable.  The  pacicet-fotwarding 

mechanlsna  of  the  network  *5*_“"*T?i^**’^* 

DCE.  Sent  in  RESET#  CLEAR  and  RESTART  packets. 


Link  level  came  up.  Sent  in  RESTART  and  RESET 
packets. 

Link  level  went  down  at  remote  DTE.  Sent  in  CLEAR 
and  RESET  packets. 

Remote  DTE  restarted.  Sent  in  CLEAR  and  RESET 
packets . 

Local  resources  not  available  for  call 
establishment.  The  local  DCE  ^s  too  few 
resources  to  establish  another  call.  Sent  in 
CLEAR  and  DIAGHOSTXC  packets. 


Remote  resources  net  available  for  call 
establishment.  The  remote  DCE  has  too  few 
resources  to  establish  another  call.  Sent  in 
CLEAR  packets. 

Remote  host  dead.  The  link  to  the  remote  DTE  is 
down.  Sent  in  CLEAR  and  RESET  packets. 


Remote  IMP  dead* 
is  attached  is 
packets* 


The  IMP  to  which  the  remote  DTE 
down.  Sent  in  CLEAR  and  RESET 


Logical  subnetwork  access  barred.  The  remote  DTE 
cannot  be  reached  because  of  a  communitles-of- 
interest  prohibition*  Sent  in  CLEAR  and  RESET 
packets. 

Connection  lost.  An  internal  error  has  occurred 
at  either  the  remote  or  the  local  XE  which  has 
made  their  virtual  circuit  data  structures 
inconsistent.  Sent  in  CLEAR  and  RESET  packets > 


Response  lost.  A  response  from  the  remote  XE 
failed  to  arrive  within  a  reasonable  time.  Sent 
in  CLEAR  and  RESET  packets. 
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A-3.2  X.25  IP  Interoperability  Considerations 

When  DDN  standard  X.25  service  is  requested  at  call 
establishment  (as  described  in  Section  2.1.2.1)r  the  call  is  in 
effect  established  between  the  DTE  and  a  local  x.2S  entity.  This 
entity  subsequently  extracts  the  IP  datagrams  from  the  X.25  data 
packets  for  transmission  through  the  DDN  Internet.  This  approach 
requires  that  certain  conventions  be  followed; 

1.  IP  datagrams  are  to  be  sent  as  X.25  complete 

packet  sequences.  That  isr  datagrams  begin  on 

packet  boundaries  and  the  N  ("more  data”)  bit  is 
used  for  datagrams  that  are  larger  than  one 
packet.  Only  one  IP  datagram  is  to  be  sent  per 
X.25  complete  packet  sequence. 

2.  By  convention,  the  maximum  IP  datagram  size  is  576 

octets.  This  packet  size  can  most  efficiently  be 
accommodated  by  negotiating  an  X.25  maximum  packet 
size  of  1024;  alternatively,  a  DTE  may  use  an  X.25 
complete  packet  sequence  to  transmit  an  IP 

datagram. 

3.  Because  the  X.25  connection  is  in  effect 
terminated  locally,  the  D  and  Q  bits  have  no 
significance  and  should  be  set  to  zero* 

4.  The  precedence  bits  of  the  IP  type-of-service 
field  are  to  be  mapped  into  X.25  precedence  bits 
(see  Section  2. 1.2. 2)  as  specified  in  Table  A«-2. 


IP  Precedence  X.25  Precedence 

000  00 

001  01 

010  10 

oil  -  111  11 


Table  A*2.  IP  Precedence  to  X.25  Precedence  Mapping 


m 


V 


ll 
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141  Calling  logical  address  not  enabled  or  not 
authorized.  Sent  in  CLEAR  packets. 

142  Calling  logical  name  incorrect  for  this  DTE.  Sent 
in  CLEAR  packets. 

143  Called  logical  name  not  authorized.  Sent  in  CLEAR 
packets. 

144  Called  logical  name  not  enabled.  Sent  in  CLEAR 
packets. 

145  Called  logical  name  has  no  enabled  DTEs.  Sent  in 
CLEAR  packets. 

146  Use  of  logical  addresses  invalid  in  this  network. 
Sent  in  CLEAR  packets. 

147  Declared  logical  name  now  in  effect.  Sent  in 
CLEAR  packets. 

148  Declared  logical  na»e  was  already  in  effect.  Sent 
in  CLEAR  packets. 

149  Declared  logical  name  is  now  disabled.  Sent  in 
CLEAR  packets. 

150  Declared  logical  nawe  was  already  disabled.  Sent 
in  CLEAR  packets. 

151  Incoming  calls  barred.  Sent  in  CLEAR  packets. 

152  Outgoing  calls  barred.  Sent  in  CLEAR  packets. 

192  Cleared  due  to  higher  precedence  call  at  local 
DCE.  Sent  in  CLEAR  packets. 

193  Cleared  due  to  higher  precedence  call  at  remote 
OCE.  Sent  in  CLEAR  packets. 

194  Requested  precedence  too  high.  The  DTE  is  not 
authorized  to  establish  a  call  at  the  requested 
precedence  level.  Sent  in  CLEAR  packets. 


Table  A-1.  Additional  Packet  Level  Diagnostic  Codes 
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A-3.3  The  DDN  Logical  Addressing  Facility 

The  DDN  logical  addressing  facility  allows  references  to 
hosts  by  either  their  physical  network  address  or  by  one  or  more 
location- independent  logical  addresses  j 

exercise  partial  control  over  the  logical  addressees)  by  which 
they  can  be  referenced*  Implementation  of  DON  logical  addressing 
by  a  host  is  optional* 

The  DDN  Administration  will  assign  seven-digit  logical 
addresses,  and  will  maintain  a  logical  addressing  data  base*  The 
host  is  then  responsible  for  notifying  the 

of  the  "names"  (logical  addresses),  if  any,  by  which  it  wishes  to 
be  known.  It  cannot  receive  calls  addressed  to  «  J'*-* 
originate  calls  under  that  name  unless  it  has  enabled  that  name. 
It  also  cannot  enable  a  name  that  is  not  author ixed  that 

physical  address*  Names  can  also  be  enabled  automatically  by  the 
network,  under  the  control  of  the  Administration* 


A-3.3.1  Logical  Addresses 

Logical  addressing  is  Invoked  when  a  called  address  is 
supplied  to  the  IMP  with  the  flag  digit  F  •  one.  The  logical 
address  consists  of  seven  BCD  digits.  This  name  is  mapped  by  the 
logical  addressing  facility  into  a  DDN  physical  network  •ddress. 
The  logical  name  need  not  be  unique  for  the  physical  address,  nor 
is  the  physical  address  necessarily  unique  for  the  name. 


A-3.3. 2  Enabling  and  Disabling  Logical  Addresses 

To  enable  and  disable  logical  addresses,  the  DDN  X;25  host 
must  send  declarative  CALL  REQUEST  packets  to  the  DCE  using  a 
called  address  with  the  format: 

ZZZZ  F  DDDDDDD  (SS) 


where  the  address  fields  are  as  described  in  Section  2.1.1. 

Flag  F  must  be  set  to  nine,  the  DON  Host  Identifier  field 
specifies  the  logical  address  under  consideration,  and  the 
subaddress  field,  which  must  be  present,  specifies  the  type  of 
transaction.  Declarative  calls  are  cleared  immediately  by  the 
local  DCE. 
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If  SS  is  zerOf  the  logical  name  is  enabled  in  normal  mode? 
that  is,  that  physical  port  will  accept  calls  to  that 
name,  and  allow  outgoing  calls  from  that  name. 

logical  name  is  disabled.  If  SS  is  two,  the  logical  address  is 
enabled  in  reverse  translation  mode)  in  this  mode,  the  called 
address  field  of  incoming  call  packets  will  be  translated  into  a 
physical  address  (i.e.,  an  address  containing  a  flag  F  •  0),  if 
it  was  given  by  the  calling  DTE  (X.25  host),  as  a  logical  address 
(i.e.,  containing  a  flag  P  -  1). 


Whenever  a  DTE  comes  up,  or  restarts,  the  logical  names  for 
that  DTE  are  returned  to  their  default  state,  which  may  be  either 
enabled  or  disabled,  as  configured  by  the  DON  Administration. 


A-4  Limitations  of  DON  Basic  X.25  Service 

The  Defense  Data  Network  is  an  Internetwork  environment. 
That  is,  DDN  as  a  whole  is  made  up  of  a  number  of  constituent 
oacket  switching  networks  that  are  interconnected  via  9«teways. 
Communication  across  gateways  requires  the  use  the  Intepet 
Protocol,  which,  for  a  host  accessing  DDN  using  X.25, 
that  the  host  implement  the  DoO  standard  protocol  architecture 
and  employ  DON  standard  X.25  service.  In  addition,  a  classified 
host  is  attached  to  a  DDN  constituent  network  of  lower 

classification  by  means  of  an  Internet  Private  Line  Interface 
(IPLI).  IPLIs,  which  themselves  contain  gateways,  also  require 
the  use  of  the  Internet  Protocol)  moreover,  they  do  not,  as 
currently  designed,  offer  an  X.25  host  interface.  These 

attributes  of  the  DDN  Internet  have  two  implications  for  users  of 
DDN  basic  X.25  service: 


1.  DON  hosts  that  do  not  implement  IP  and  higher- 
level  DON  protocols,  and  which  use  only  DON  basic 
X.25  service,  cannot  communicate  across  gateways. 
Their  network  communication  is  therefore 
restricted  to  a  single  DDN  constituent  network. 

2.  X.25  hosts  cannot  be  provided  classified  service 
on  a  constituent  network  of  lower  classification. 
Should  X.2S  host  access  be  developed  for  the  IPLI 
in  the  future,  classified  network  access  will  be 
made  available  to  hosts  using  DON  standard 
service  only. 
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A-5  Derivation  of  DDN  X.?.5  Addtessos 

All  DDN  hosts  art  assigned  addresses  by  the  Adninistration. 
The  address  of  a  DON  host  eay  be  obtained  from  the  Network 
Inforaation  Center  (NIC) ,  represented  as  an  A$C11  text  string  in 
what  it  called  'host  table  fornat."  This  section  describes  the 
procetts  by  which  DON  X.2S  addresses  in  the  fornat  described  in 
Section  2.1.1  My  be  derived  from  addresses  in  NIC  host  table 
format. 

A  NIC  host  table  address  consists  of  the  ASCII  text  string 
representations  of  four  deciMl  numbers  separated  by  periods, 
corresponding  to  the  four  octets  of  a  thirty-two  bit  Internet 
address.  The  four  deciMl  numbers  are  referred  to  in  this 
section  as  'n*.  'h',  'I*,  and  'i*.  Thus,  a  host  table 
may  bt  rtprtatnttd  as  "nehelei*#  Each  of  thtat  four  nusbtrs  will 
hava  tlthar  ontp  two»  or  thrtt  daciaal  digits  and  will  ntvtr  havt 
a  valut  ortattr  than  255.  For  axanplt#  in  tht  host  table  address 
•10e2.0.124*»  n»10p  h*2,  1»0,  and  l«124.  To  conveit  a  host  table 
address  to  a  DDN  X.25  address x 

1.  Xf  h  <  «4p  the  host  table  address  corresponds  to 
the  DDN  Xe25  physical  address 

mi  r  xixBBxz  iss) 


herex 

till  •  0000 

as  required  in  Section  2el.l«lelx 

r  •  0  because  the  address  is  a  physical 

address I 

IIX  is  a  three  deciMl  digit 

representation  of  •!“,  right-adjusted 
and  padded  with  leading  xeros  if 
required; 

HR  is  a  two  decinal  digit  representation 

of  'h*,  right-adjusted  and  padded 
with  leading  xercs  if  required; 


ZZ  »  00 

and 


(5S)  is  opticnal,  as  described  in  Section 
2.1.l.le. 
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In  tht  txaoplc  9ivtn  iitjovt#  the  host  table  address 
10,2. 0.124  corresponds  to  tne  DON  X.25  physical 
address  000001240200. 

2.  If  h  >  64  or  h  -  64 r  the  host  table  address 

corresponds  to  the  DON  X.25  logical  address 

2ZZZ  F  AHRRRZZ  (SS) 

where: 

ZZZZ  •  0000 

as  required  In  Section  2.1.1.1*!: 

p  «  1  because  the  address  Is  a  logical 

address: 

RRKRR  Is  a  five  declnal  digit 

representation  of  the  result  “r*  of 
the  calculation 

r  «  h  *  256  ^  1 

(note  that  the  de::l»al  representation 
of  "r*  will  always  require  five 
digits) t 

tl  •  00 

and 

(SS)  Is  optional f  as  described  In  S^tjctlon 

2.1. 1.1. 4. 

Thus,  the  host  table  address  10. B3. 0.207 
corresponds  to  tht  DDN  X.25  logical  address 
000012145500. 

In  both  easts,  the  "n"  and  "I*  fields  of  the  host 
address  art  not  used. 
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APPENDIX  E:  DDN  Synchronous  Level  1  Specification 


B-1  Introduction 

A  host  may  connect  to  the  Defense  Data  Network  at  the  link 
level  using  the  asynchronous  bit  serial  protocol  described  in  3BN 
Report  No.  1822  as  either  a  local  host  (LH)  or  a  distant  host 
(DH) .  A  host  may  also  connect  to  the  DDN  by  means  of  a 
synchronous  bit  serial  protocol  at  the  link  level,  either 

the  method  described  in  BBS  Report  No.  1822,  HDH,  or  the  DDN  X.23 
interface.  Neither  LH  nor  DH  is  recommended  for  new 
implementations • 

This  section  describes  the  functional#  electrical#  and 
mechanical  connection  (the  level  1  connection)  that 
when  either  an  HDH  or  an  X.25  host  is  connected  to  the  DDN. 
Hosts  connecting  to  the  DDN  via  HDH  or  X.25  require  a  synchronous 
modem  connection  or  the  equivalent#  which  will  be  supplied  as 
part  of  the  DDN  service.  The  host  will  present  the  DTE  interface 
while  the  DDN-provided  equipment  will  present  the  DCE  interface. 

A  long-term  goal  of  the  DDN  is  for  all  level  1  connections 
to  be  accomplished  with  the  WIL-188-114  ba^nced  interface.  Its 
general  equivalents  are  EIA  RS-449/422#  CuITT  V.ll,  and  Fed.  Std. 
1031/1020.  The  DDN  cannot  implement  this  at  present  due  to  the 
limited  availability  of  commercial  vendor  hardware.  In  order  to 
facilitate  future  DDN  compatibility#  all  new  system  acquisitions 
should  specify  MIL-188-114  balanced  as  a  required  interface#  m 
addition  to  an  alternate  interface.  The  selection  of  an 
alternate  interface  should  not  preclude  utilization  of  the  hil- 
188-114  balanced  interface  when  it  becomes  supportable. 


B-2  Supported  Interfaces 

DDN  presently  supports  four  synchronous  level  1  interfaces. 
They  are: 

1.  EIA  RS-232-C..  CCITT  V.28  &  V.24; 

2.  MIL-188-114  balanced#  EIA  RS-4494422#  CCITT  V.ll# 

Fed.  Std.  1031/1020; 

3.  MIL-188-114  unbalanced#  EIA  RS-449i423#  CCITT 
V.IO#  Fed.  Std.  1031/1030;  and 
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4.  CCITTV.35. 

Table  B-1  is  a  dictionary  of  terms  that  relates  the  CCITT 
siqnal  ID  to  the  EIA  signal  ID  and  to  the  more  commCii 
abbreviations.  Table  B-2  identifies  signals  as  either  required, 
optional f  or  not  used. 

Fiqure  B-1  and  Table  B-l  identify  typical  DTE  connections  to 
the  DDN.  The  required  subscriber  services  will  dictate  whiCa* 
scheme  is  selected  for  a  particular  DTE. 

Table  B-4  relates  required  speed  of  service  to  interface 

type. 

Together,  these  tables  and  figures  serve  as  a  guide  to  level 
1  interface  selection.  From  these,  most  systems  will  be  able  to 
identify  the  most  appropriate  interface.  However,  this 
information  is  not  all-inclusive.  Other  interface  arrangements 
may  be  possible;  contact  your  DDN  representative  for  assistance 
as  required. 


Demarcation  Point 
(mating  connectors) 


DTE 

- J 

DCE 

(1) 

Modem 

RS-232-C 

1 

1  1- 

- 1 

i - 

(2) 

Modem 

V.35 

—  1  —  1  — 

1— 1 

[— — — . 

(3) 

LDM 

RS-2:2-C,  MIL-18B-114 

1 

[ - 

(4) 

Null 

Modem  Cable 

HOST 

1 

[ - 

(5) 

SME 

Cable  plus  clocic  source 

j  ^ 

( - 

(6) 

DCS 

mil-188-114 

1  1 

II - 1 

(— - 

(7) 

DES 

RS-232-C,  RS-449,  V.35 

1  1 

1  1“ 

- - - 1 

[ - 

(8) 

KG 

MIL-188-114  balanced 

1 

- J 

[ 

(9) 

IPLI 

HIL-188-114  balanced 

Figure  B-1.  Typical  Level  1  Connection  Schemes 
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EIA 

CCITT 

ABBREl? 

NAME 

ID 

ID 

NAME 

AA 

101 

FG 

Frame  (Chassis/Protective)  Ground 

AB 

102 

SG 

Signal/Supply  Common 

SC 

102a 

-- 

RS-449  DTE  Common 

RC 

102b 

RS-449  DCE  Common 

BA 

103 

TD 

Transmit  Data 

BB 

104 

RD 

Receive  Data 

CA 

105 

RTS 

Request  to  Send 

CB 

106 

CTS 

Clear  to  Send 

CC 

107 

DSR 

Data  Set  Ready 

CD 

106.2 

DTR 

Data  Terminal  Ready 

CP 

109 

DCD 

Data  Carrier  Detect 

CG 

110 

SQ 

Signal  Quality 

CH 

111 

Signal  Rate  Selector  to  DCE 

Cl 

112 

» 

Signal  Rate  Selector  to  DTE 

DA 

113 

ETC 

External  Transmit  Clock 

DB 

114 

TC 

Transmit  Clock 

DD 

115 

RC 

Receive  Clock 

116 

— 

Select  Standby 

117 

— 

Standby  Indicator 

SBA 

118 

STD 

Secondary  Transmit  Data 

SBB 

119 

SRD 

Secondary  Receive  Data 

SCA 

120 

SRS 

Secondary  Request  to  Send 

SCB 

121 

SCS 

Secondary  Clear  to  Send 

SCF 

122 

SCD 

Secondary  Carrier  Detect 

SCG 

123 

SSQ 

Secondary  Signal  Quality 

124 

•>,. 

Select  Frequency  Group 

CE 

125 

RI 

Ringing  Indicator 

126 

— 

Select  Transmit  Frequency 

127 

Select  Receive  Frequency 

128 

External  Receive  Clock 

129 

RR 

Request  to  Receive 

MM 

130 

Secondary  Transmit  Tone 

MM 

131 

Receive  Character  Timing 

MM 

132 

Return  to  Non-Data  Mode 

MM 

133 

RTR 

Ready  to  Receive 

134 

.1^ 

Received  Data  Present 

MM 

136 

New  Signal 

Mi»  - 

140 

RL 

Remote  Loopback 

MM 

141 

LL 

Local  Loopback 

MM 

142 

TM 

Test  Status  Monitor 

191 

Transmit  Voice  Answer 

MM 

192 

— 

Receive  Voice  Answer 

Table  B-1.  EIA  and  CCITT  Interchange  Circuits 
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Requited: 


101,  102,  103,  104,  105,  106,  107,  108.2, 
109,  113,  114,  and  115 


Cptional: 


110,  125,  140,  141,  and  142 
(These  may  be  required  lAW  future  DON 
developments;  it  is  strongly  recommended 
that  these  at  least  be  available  for 
implementation  upon  requirement) 


Not  used: 


111,  112, 
123,  124, 
133,  134, 


116,  117, 
126,  127, 
136,  191, 


118,  119, 
128,  129, 
and  192 


120,  121, 

130,  131, 


122, 

132, 


Table  8-2.  Signal  Selection  by  CCITT  Interchange  Circuit  Number 
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(8)  KG  KG  devices  are  U.  S.  Government  encryption 

devices  under  strict  NSA  control.  The 
requirement  for  security  and  KG  devices  requires 
the  selection  of  the  HII,-188-114  balanced 
iftterf acsc 


(9)  Internet  Private  Line  Interface 

IPLI  devices  are  security  level  community  of 
interest  isolation  devices.  The  requirement  for 
IPLI  service  requires  the  selection  of  the  MIL- 
188-114  balanced  interface. 


Notes  and  ronsif^Aratlons 

1.  Interface  (2),  Modem,  48Kb/s  is  generally  only 
available  O-CONUS. 


2. 


MIL-188-114  balanced  is  deemed  «<I«ivalent  to  RS-449 
with  RS-422,  the  difference  being  that  MIL-188-114 
more  tolerant  of  noise  on  signal  common  and  more 
tolerant  of  common  mode  noise. 


is 


3.  MIL-188-114  unbalanced  is  deemed  «<l“ivalent  to  RS-449 

with  RS-423.  In  most  cases  where  MIL-188-114  balanced 
is  specified,  MIL-188-114  unbalanced  is  also  available, 
but  it  is  not  recommended. 


4.  There  are  system  enhancements  under  long  term 
development  for  use  in  the  DDH  which  may  request 
additional  control  leads  beyond  those  listed  as 
required.  The  implementation  of  these  enhancements 
will  not  limit  operational  capabilities  but  may  impact 
the  ability  of  the  Network  Monitoring  Center  to  assist 
with  host  and  host  access  line  diagnosis.  These 
enhancements  may  request  signals  from  the  optional 
category. 


Table  B-3.  Typical  Level  1  Connection  Schemes 
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Scheme  (From 
Fig,  B-1) 

(1)  Modem 

(2)  Modem 


Explanation 

RS-'232  at  speeds  of  1200^  2400f  4800^  9600  or 
14400  b/s  over  long  haul  leased  voice  grade 
telephone  facilities 

CCITT  V.35  at  speeds  of  48,  50,  56,  64  Kb/s  over 
leased  group  (37KH2)  grade  facilities  or  in  CONUS 
the  Digital  Data  Service  facilities. 


(3)  Limited  Distance  Modem 

LDM  generally  available  at  9600  b/s  and  below  in 
an  RS-232  version.  Other  types  are  available  for 
all  speeds. 

(4)  Null  Modem  A  Null  Modem  is  a  length  of  cable  with  the  signal 

leads  crossed  so  as  to  present  a  DCE  interface. 

To  be  used  in  local  connection  schemes  where 
either  the  DTE  or  the  DCE  has  a  clocking  source 
capability.  All  four  supported  level  1 
interfaces  are  available.  If  DTE  clock  and  DCE 
clock  are  both  available,  DTE  clock  will  be 
preferred. 


(5)  Synchronous  Modem  Eliminator 

SME  is  a  length  of  cable  with  a  hardware  device 
interjected.  The  device  allows  convenient 
crossing  of  signals  so  as  to  present  a  DCE 
interface.  The  device  also  provides  clocking 
when  neither  the  DTE  nor  the  DCE  has  such 
capability.  All  four  supported  level  1 
interfaces  are  available. 


(6)  DCS  Microwave 

DCS  is  generally  a  military  microwave  system 
which  provides  the  MIL-188-114  balanced  or 
unbalanced  interfaces.  It  implies  a  speed  of  50 
Kbps  and  is  usually  found  O-CONUS.  Selection  of 
this  scheme  requires  selection  of  (4)  or  (5). 


(7) 


Data  Encryption  Standard  .  . 

DES  is  a  commercial  encryption  device  used  by  the 
DoD  as  a  privacy  device.  DES  is  available  with 
either  RS-232,  V.35,  or  RS-449/422. 
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Signaling  Rate  in 

Kb/s 

Physical 

Interface 

1.2 

2.4  4.8  9.6  14.4  48 

SO 

56 

64 

100 

RS-232-C 

R 

RRRR*- 

- 

- 

- 

*• 

KIL>188-114 

A 

AAA-- 

- 

- 

- 

- 

unbal.  ((  equlv.; 

1 

HIL-188-114 
bal.  (4  equiv.) 

A 

A  A  A  A*  A 

A 

A 

A 

R** 

CCITT  V.35 

- 

-  -  -  -  R 

A 

R 

R 

A 

R  « 

Recommended 

A  »  Avallablt 
«  «  Not  available 
*  «  Only  available  uaing  modems 
**  ■  Only  available  using  a  local  cable 
connection 


Table  B-4.  Interface  Type  by  Service  Speed 
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Signal  Mane 


Frane  Ground 
Trananitted  Data 
Received  Data 
Request  to  Send 
Clear  to  Send 
Data  Set  Ready 
Signal  Ground 
Data  Carrier  Detect 
Transnit  Clock 
Receive  Clock 
Data  Teminal  Ready 
Ext.  Transnit  Clock 
Wired  Spare 
Wired  Spare 
Wired  Spare 


Abbrev 

Pin  No. 

EIA  ID 

Signal  Source 

FG 

1 

AA 

DTE/DCE 

TD 

2 

BA 

DTE 

RD 

3 

BB 

DCE 

RTS 

4 

CA 

DTE 

CTS 

5 

CB 

DCE 

DSR 

6 

CC 

DCE 

SG 

7 

AB 

DTE/DCE 

DCD 

8 

CP 

DCE 

TC 

15 

DB 

DCE 

RC 

17 

DD 

DCE 

DTR 

20 

CD 

DTE 

ETC 

24 

DA 

DTE 

18 

— 

••• 

22 

••• 

— 

25 

— 

••• 

Required  pinss  1#  2$  4#  5#  7,  15»  17,  20,  24 

Optional  pinsi  9,  10,  18,  22,  25 


1.  The  DTE  will  present  a  CANNON  DB-25P  male  connector 
with  pinouts  as  above  or  equivalent  hardware  with 
identical  pinouts. 

2.  The  DCE  will  present  a  CANNON  OB-25S  female 
connector  or  equivalent. 


Table  B-5.  RS-232-C  Interface 
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Signal  Nana 


Sand  Data 
Sand  Timing 
Racaiva  Data 
Raquast  to  Sand 
Racaiva  Timing 
Claar  to  Sand 
Local  Loopback 
Data  Moda 
Tacminal  Raady 
Racaiva r  Raady 
Ramota  Loopback 
Tarminal  Timing 
Tast  Moda 
Signal  Ground 
Racaiva  Common 
Sand  Common 
Wirad  Spara 
Hirad  Spara 


Abbrav 

Pin  Mot. 

ElA  ID 

Signal  Source 

SD 

4p22 

BA 

DTE 

ST 

5,23 

DB 

DCE 

RD 

6,24 

BB 

DCE 

RTS 

7,25 

CA 

DTE 

RT 

8,26 

DD 

DCE 

CTS 

9,27 

CB 

DCE 

LL 

10 

— 

DTE 

DM 

11,29 

CC 

DCE 

TR 

12,30 

CD 

DTE 

RR 

13,31 

CF 

DCE 

RL 

14 

•• 

DTE 

TT 

17,35 

DA 

DTE 

TM 

18 

DCE 

SG 

19 

AB 

DXE/DCE 

RC 

20 

RC 

DCE 

SC 

37 

SC 

DTE 

1 

•••• 

— 

3,21 

— 

— 

Raqulrad  pinst 
Optional  pint I 


4,22j  5,23»  6,24j  7,25j  8,26,  9, 27i 
11,29,  12,30,  13,31,  17,35,  19,  20, 
10,  14,  18,  1,  3,21 


37 


aflttH 

1.  Th*  DTE  will  prtstnt  a  CAKNON  OC-37P  malt  connactot 
with  pinout!  ai  abova  or  aqulvalant  hardwara  with 
identical  pinout. 

2.  Tha  DCB  will  praiant  a  CAMNON  DC-37S  famala 
connector  or  aquivalant. 


Table  B-6.  MIL-188-114  Interface  (and  equivalent!) 
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Signal  Mane 


Frame  Ground 
Signal  Ground 
Transmit  Data 
Receive  Data 
Request  to  Send 
Clear  to  Send 
Data  Set  Ready 
Data  Carrier  Detect 
Local  Loopback 
£xt.  Transmit  Clock 
Transmit  Clock 
Receive  Clock 

Required  Plnsi 

Optional  Plnss 


Abbrev  Pin  Nos.  EIA  ID  Signal  Source 


FG 

A 

SG 

B 

TD 

P/S 

RD 

R/T 

RTS 

C 

CTS 

D 

OSR 

E 

DCD 

F 

LL 

R 

ETC 

u/w 

TC 

Y/aa 

RC 

V/X 

A>  B; 

P/S;  R/T;  C 

V/X 

R 


AA 

DTE/DCE 

AB 

DTE/DCE 

BA 

DTE 

BB 

DCE 

CA 

DTE 

CB 

DCE 

CC 

DCE 

CF 

DCE 

— 

DTE 

DA 

DTE 

OB 

DCE 

DD 

DCE 

B;  P;  0/W^  Y/aar 


Waft 

1.  The  DTE  will  present  a  Winchester  HRA(C)-34D-JTCH-H8 
Ml.  conn.ctot  with  pinout  m  abov.  ot  ^julval.nt 
hardwac.  with  th.  id.ntical  pinout. 


2.  Th.  OCE  will  pr.f.nt  a  Mtinq  fwnal.  connactor. 


Tabl.  B-7.  V.35  Int.cfaca 


B-10 


1-508 


MILITARY  STANDARDS:  X.25 


APPENDIX  C 

Fedml  Informatioa 
Procetsiiig  Standards  PubUcation  100 

Federal  Standard  1041 

19Ca  July  6 

ANNOUNCING  THE  JOINT  STANDARD  FOR 


INTERFACE  BETWEEN  DATA  TERMINAL  EQUIPMENT  (DTE) 
AND  DATA  CIRCUIT-TERMINATING  EQUIPMENT  (DCD 
FOR  OPERATION  WITH  PACKET-SWITCHED  DATA 
COMMUNICATIONS  NETWORKS 


PMml  tatoamm  PwwMwg  friiiiwh  Md  mmd  ^  tte  Htticmi  Mmmm  1*"*^  Jf 

Mcnea  111(0(2)  of  tht  FMmI  Profwrry  Md  Adowwwrawio  Wnowi  Act  of  IMf.  «  aoNOAid.  PoWic  Low  I9-3M  Stac.  Iim 
Eaoeoiivt  Ord«  1 1717  (Jl  Fa  1231 J.  daiod  May  1 1  I WJ).  «id  fan  *  of  TWt  IS  Coda  of  Fad«ai  Rardaooaa  (CFS) 

FadanI  SiaMtfda  la  tte  “ii1|-oit-iii-tt - aanai  aaa  davalopod  by  tlw  omca  of  iha  Miaaiaf.  Naooaai  Coawaainanoaa  $y«a». 

TInm  Fadtral  SuAdM^  «t  «nad  by  tha  Ooaarai  Sarvicaa  Adiaiairanna  panaaat  lo  tba  FadanI  Froparry  aad  AdauaiaOTnva 
Sarvien  Aa  of  IMt.  aa  anaadad 


Neat  df  Siawlirdt  Inttrfftfft  Ddtwtto  Dta  Ttmiiial  Equipaxst  (DTE)  tad  Dtii  QrcuttTtfTBiBitmg 
Equipmcet  (DCE)  for  Opcnnoo  with  Paektt-Swiiched  Dut  ComsBomcsiioot  Networks. 

Cettfery  ofSciaM:  Hardwire.  Dttt  Tnotmitsiosi. 

rif^eMrrfirrr  Fedenl  aetomned  data  proctsnsii  eqeipmenL  serviea,  od  ttiecocpm«ttcatioo  aquinmiPt 
oitaf  public  peekti<iwuebcd  data  ooauDo&ieatioQt  networks  (PSDCN)  beaed  oe  tbe  tenily  of  CCITT 
ReeooMseadatioQS  derived  froa  X 1  and  XJ  shall  employ  the  iateite  and  protocols  spedOed  » this  )om( 
stasdaid.  la  deitfDcn  of  these  mteraeUy  operated  aad  maimained  Federal  netwoits  employmi 

pecket*switchad  teehaoloiy  should  consider  the  use  of  this  interface  as  appropriate.  The  joint  standard 
provides: 

-  A  (amUy  of  physical  layer  interfaees.fm  which  a  pertieular  interface  may  be  selected;  and 

«  A  stnfle  darn  link  layer  control  procedure;  and 

*  Packet  level  procedorts  for  vimtal  calls  aad  permanent  virtual  drcutis.  aivi  aa  optional  daiafram 
operation. 

The  mandatory  mierfMM  attributes  of  this  joint  standard  art  suaaiarisnd  as  follows: 

PHYSICAL  LEVEL 

Traaamission  raim:  14.  4.1. 9.d  Kbits/s 

buerfaor  on«  or  more  of  the  foUowmi:  RS*231-C  X21.  R$449 


LINK  LEVEL; 

Procedure:  LAPB 

Parameter  X  ^ 

Smallest  Nl:  1640cteis 
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PACKET  LEVEL: 

Services: 

Packet  types: 

User  diu  fleld 
length: 


Virtual  call  and  permanent  virtual  circuit 

All  basic  plus  Diagnostic  packets.  Packet  Reject  shall  not  be  used. 

Octet-aligned 


Packet  sequence 
nufflbanng: 

D  bit  procedure: 


X.25  diagnoade 
codas: 

Fast  Selaet: 


Interrupt  packet: 

Duplicated  fiKUlity 
codes: 


Modulo  S 

Supported  by  ^dl  DCEa;  DTE  need  not  employ  the  D  bit  whan  sending  to 
the  OCR  but  no  DTE  shaU  rqjact  incoming  packet  with  the  D  bit  set  to  I  or 
0  as  having  this  bit  in  error  unless  it  is  known  by  receiver  that  the  sender 
has  no  D  bit  capability. 

Use  nandard  codes  whenever  they  apply;  non-sid  codes  may  be  used 
for  events  not  listed  in  XOS  within  a  peM  of  24  months  after  the  affective 
date  of  this  standard. 

DCEs  shaU  implement  fast  select;  DTE  need  not  employ  fttt  select  when 
sending  to  DCR  but  all  OTEs  with  higher  level  ftmctionality  which 
allows  response  to  fast  select  must  be  able  to  accept  incoming  fast 
selaet  peckeL 

Receipt  of  a  DTE  interrupt  packet  befare  a  previous  DTE  inienupt 
packet  has  bean  eooflnned  is  an  error  eondidon. 

Tlw  laei  appealing  (ktltty  code  should  be  treated  by  the  DTE  as  if  it 

were  the  only  appearance  of  that  code. 


Non-iero  cauae  (Idd  Discarded 

of  reaiait  request 
peeket: 

Reamn  requeet  too  Dbcaided 

long  in  state  rl: 


This  joint  standard  is  intended  to  enhance  interoperability  by  spediying  certain  subeeti  and  other 
cotNtnustts  on  Federal  uae  of  Cernr  Recommendatioo  X.25. 

The  Government's  imem  b  employing  this  joint  standard  is  to  reduce  the  coat  of  acqutrmg  a^  us^ 
Federal  iiirnmaiail  data  prooamiag  eqmpment.  services,  and  telecoeHmuniretion  equipmeni  with  PSDCN. 
The  joint  standard  u  also  to  reduce  the  coat  of  acquirtag  and  uamg  Oovemment-owned  or  leased 

PSDCN.  These  goals  wiU  be  achieved  br 

-  Increasing  the  available  alternative  sources  of  supply; 

*  Incraeaing  the  fautiHiaiinn  of  Government  raaoureas;  and. 

•  AiMrtBg  the  requtrnd  mteroperabOlcy. 

Apprevkag  Auihedtr  Secretary  of  Commerce  OFederal  Information  Proeeming  Standards).  AdmtniarTiiOf. 
General  Services  Admaimnoom  (Federal  Standards). 

— T - Afsner  The  Nadonb  Bureau  of  Standards  and  the  Office  of  the  Meneget.  Nedone) 

Commuaicetions  Syetem  will  jointly  *»«***^  thia  standard  coord  mating  sa  necemnry  with  tht  Gcntral 
Services  Admtniairasioe  (GSA). 
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Crwi  TTie  following  tre  reUted  sundirdt  upoo  which  thti  FIPS  PUB  is  btiod.  The  incluiioii  of  i 

partiettlar  suodard  on  this  list  does  not  necessarily  mean  that  the  staadaid  is  applieabie  in  all  cases  to  which 

this  RPS  PUB  applies.  ^  ^ 

(a)  Inienabonal  Standard  2110*1980;  Dau  Cammnjiicerioa— DTE/DCE  tnwfaet  Conntetof 

and  fin  AMStgimintk  _  .  , 

(b)  Telegraph  and  Telephone  Consultative  Committee  (CCITT)  Recommendation  v.24 
(1980);  Lin  ^  D^finMons  /or  Iittarchangt  Orcuia  Batman  Data  Tarminal  Equipmant  end  Dam  Omait 

Tarmiimtint E^juipmant  .  ^  ^ 

(c)  CCmr  Recommendation  V.:8  (1980);  Eketrkal  Ommemrinka  fdt  Uatalanead  Deabk-Cumai 

Intarchengt  Clnuitt 

(d)  Electronics  Industries  Ajsociatioo  (EIA>  RS*232*C  (1969  August):  Intarfaea  Batman  Dam 

rafmna/£pupmaniandDamCammankaiioa£fMipmam£mpi^SafmiBmarr 

<e)  lntfTna*My»*l  Standard  4902*1910:  Dam  Cammimieatma^T^fin  and  9^fin  DTE/DCE  Intarfaea 
Cannaetan  and  fin  AaiinmantL  .  ^  ^ 

(0  CCrrTRmommendaiion  VJia2‘0(1980>:£liefric*/Chemefirirta>B^^ 

/ntarekanga  Ciratitt/mGanarai  Urn  wUk  Inmramd  Cirtmt  JSpdfnmnt  in  tha  flaidqfDam  Cammunieatmrn, 

(g)  BURS422.A  (1978  June);  Elseirkn/akeaaefemrifl^BakiieirfKei^ 

(h)  Federal  Standard  1020A  (1980  January);  Taiaeemnntnkarinnr  Eiaeoieat  Omraetaruoa  of  Baianead 

yoitaga  Digimi  Intarfaea  OreuiOL  .  - 

Cl)  ccrrr  Recommendanon  V.IO  (X26)  (1910):  Skttrkai  Omramrima  faa  Undakumad  Dea^ 
Ci^rant  Intartdania  Ortuio  for  Ganami  Vm  mtk  Inmraud  Qradt  Mfaipmant  in  tka  field  gf  Dam 
Conununieatmim 

(j)  EIA  RS423*A  (1978  June);  Elaetrieal  Ckaraetarittia  a(  Vnkaknead  VaUagt  Digimi  Intatfaea 
Cireuim 

(k)  Federal  Standard  1030A  (1980  January);  TeJeewnniiieieealaer  ElaetrimI  Charaemrutia  of 
Vnkaknead  Volmgt  Digital  Intarfaea  Ckeuia 

(l)  CCITT  Recommendation  XJUbis  (1980);  Urn  an  fakUe  Dam  Satmeks  of  Dam  Tarminal  Efaipmant 
wkek  era  Daaignad  far  Intatfaeing  m  Spn^mnaats  V^Saria  Madmt 

(m)  CCITT  Reoonu»eadaiionV.54  (1980);  Latp  few />fs<eef>i#edae^ 

(a)  EU  RS-a9  (197?  November);  Gamral  fartmar  $7-fmitmn  and  ^^faemon  Intarfaea  Barman  Dam 
Tarminal  Egnipmant  and  Dam  OreaihTerminaiingEgakm^  _  ^  , , 

(o)  Federil  Standard  1031  (1980  June);  Takeammnnaratknt  Ganaral  fargam  S7*faaitian  and  9*/w»ee 

Inm^  Barman  Dam  Tarminal  Egmpmant  and  Dam  Cirtmt  Tirmtaerieg  Egnifmeni  (Imptememg 
inmrucboea  in  the  form  of  a  Federal  Property  Mansfement  Ragulatioe  hive  aoi  y«  bes®  mned  The 
OcBcral  Scrvioas  Admtnisvaiion  is  eonakkriag  eancefling  FED*STD  1011.  Furthermore,  a  Federal 
Informatioe  Proemdng  Standard  for  AOP  applicaiioes  cor^ondwg  to  Fedanl  Standard  1031  has  not 
been  adopted  by  Che  National  Bureau  of  Standards.)  ^  - 

(p)  Iatcraaii««al  Standard  4903-1980;  Dam  Camnmnkation’^IS^fin  DTE/DCE  Intarfaea  Connaemr 

and  fin  AotgntrmniL 

(q)  EU  Industna)  Electronics  Bulletin  No.  12  (1977  November):  AppBeatm  Nam  am  Intareonmetmn 

Batman  Intarfaea  Cvenia  Vtmg  AS-449 and ES*2I2'^ 

(r)  Draft  ImcmeiiOBal  Standard  2393  (1980):  Dam  G>ennMeipeiiee  DTE/DCE  Intarfaea 

Cannaemr  and  fin  Atagnmanm  ^ 

(s)  CCITT  Recommendation  V.35  (1980):  Dam  Tranxmmmn  at  4i  Eikkio  par  Second  Vakg  N>^I0B 

kHt  Gram  Band  Ciratdi 

(0  CflTT  Utrnw-iirrttBTi  *  7‘  *  Q«««  Ttmumtl Smutmtu 

(>)  CCTTT  Tla-nmirinrtninT  V.s  (IMO):  Smittvilmim  tf  DutStmOft 
Dm  JViWiinnit.  m  tkt  Cmn/imitM  ,  ,  . 

(v>  CCITT  r«rmiiwmi1.TiiT-  V.*  {!»•(»:  ii.»<.wfmfiw»  V  Dm-Si$mai»t  *•*«  M  Sjmcimma 
Dm  Tmtumam  m  Ltm^  Tfpt  Gratia 

(•)  Aa>tncM>  NmictwI  $m>difd  Xi.l  lT?*: Sr^taf  MtmM Om  Trmmiam. 

(i)  Federal  Information  Processing  Standard  Publicsnon  22*1  (1977  Sapmmkan.  Sjmekron^ 
Ycm/fitf  Earn  Barman  Dam  Terminal  and  Dam  Cammmmeatmm  Efmpmami.  (FTPS  PUB  22  1  n  idcntiM 
alwsaFED-STD  1013.) 
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I  (y)  Ftdtnl  Suadird  1013  (19T7  Aoguit):  Ttkeommunkatioiu:  Sjmehronotfs  S^mUini  iUam  Btfmmt 

Dam  Ttrmimi  Equipmmu  ami  Dam  CiKuit*T*rmimtitti  Sqaipmtai  l/tUUag  4  kBz  Qmiitt  (FED-STD  1013 
ti  idcatiAid  also  ai  FIPS  PUB  22.1.) 

(a)  Amaricia  Natnoal  Standard  X3.36.1973:  SyiKhnmma  HighSptad  Dam  SigaaUaf  Rami  Rttwam 
Dam  Tarrnimi  Equi^mtat  and  Dam  CommuiUeatioa  E^aipmaaL 

(aa)  Fadtrai  lofonBaaon  Proewaiag  Standards  PnMkadoo  37  (1979  J^y.  Synehmmat  Hlgk  Sptad 
I  Dtst  S^aaUoi  Rami  Raimm  Dam  Tamiaai  Efuipmmtt  and  Dam  Carntr^onkadant  Epuipmant  (FIPS  PUB 

I  37isidcndMalaoMFEZ>.STD1001.) 

(ad)  Fadaral  Standard  1001  (1975  Jnac):  Ttkeommankadonr  Spnekronont  Sigh  Spmd  Dam  Signalini 
Ram  Batwam  Dam  Teminai  Epaipmtnt  and  Dam  Cammunkmiam  Epaipmaat  (PEDSTD  1001  la  idaotifkd 
also  «  FIPS  PUB  37.) 

(ac)  ElARS^BiimSaBnanySjmdtmnamSi^mii^RamMD^TmamkmiL 

(ad)  IsTwnadonai  Standard  3309*1979:  Dam  Camnmnkatim  Hlfk^Lani  Dam  Link  Conaoi 

iRraeadam^^Fmm  Smtemn. 

(at)  Intamarional  Sisadard  4339*1979:  Dam  Cammankadon^tgk^Mi  Dam  Link  Contrai 

Rracidam^Ekmtna  of  Rmtdam, 

(aO  Addtndt&a  1  to  latamatiQaal  Standard  4339*1979:  Dam  Cammankatkm*^iik*Linai  Dam  Link 
ConmiRmeadum  •Ekmtna  of  Pfoeadmm, 

(ag)  Addodna  2  to  Istanadooal  Standard  4339*1979:  Dam  Cammunkatkn^itk-Lami  Dam  Link 
Cononi  Rmeadam  Ekmana  ^j/Pfomduma 

(ah)  IntamattOMl  Staadiad  4296*1910!  Dm  €amnmnkmion^iih4^  Dam  Link  Contrai 

Rraanium  Rakncad  Om  ^  Praeaditfat 

(ai)  Amaneam  KasoanI  Standard  X3.66.1979:  Admnead  Dm  Cammankadan  Control  haoadum 
(ADCCn 

(id)  Ftdvil  Udratdon  Prnnsain  Standards  Pthhcation  71  (1910  May)  u  rtvtstd  by  tht  Ftdtral 
MM$iatar  aetiea  47  FB  23791.  c'aitd  Jama  1. 1912  snd  amctod  hy  tht  oottet  47  FB  29397  dasad  Jma  11. 
I  1912:  Admntad  Dm  Cammankadan  Contrai  Rraeadarm  UDCCRIl  (PIPS  PUB  71  m  lathaieaUy  :oiiittnt 

I  with  FED4TD  1003A.} 

(ah)  Ftdtfal  lafonBidot  Frooasinf  StMdards  Pthlicarion  7t  (1990  Sfptcahtr):  GaidiHna  M 
impkmmtlnf  AdmncaR  Dm  CpftiwtsAwfiat  Contrai  Rratadarm  (ADCCJRk 

(aO  Fddaal  Standard  1003*^  (1961  Aapmy  takaammmnkamn:  Syndmnam  RlaDrmnmd  Dm  Link 
Control  Rraeadarm,  (FCD4TD  1303A  m  mOmkaity  ommmm  wdh  FIPS  PUB  71.) 

(ani)  CCITT  Racommaadaim  3C.29  (1990):  /aanjto  Batman  Dm  Tarm.iimi  Epkpmtnt  fDTE)  and 
i  Dm  OreaihTtramnartni  Ekdpmant  (DCEl  M  Tarminak  Optrahnd  k  ka  Raekat  )dada  an  RakBe  Dm 

^  Sarmrka 

(an)  Draft  Propomd  latanat^nai  Standard  7499:  Dm  Rmnannp  Cptn  Sjmn*i  intartannaetian^ 
Book  Raftnnea  ydadoL 

(an)  CCTTT  Bneomncndadoi  XI  (1990):  inmmatknai  Dkr  Ckarn  of  Sarkea  in  RatHe  Dam 
Narmrki 

(ap)  CCITT  tarnnwiiiailsiina  >12  (1990):  Intarnahanal  Vmr  Faailkks  in  Raklk  Dm  Satmekn 
(aq)  CCITT  f  ammtadsrion  X.96  (1990):  CaO  Awgnw  Sipnah  m  Raklk  Dm  Sarmrka 

tipMnthmtr  Tilt  ttchnieai  ipteiAewioai  of  this  jam  nandnrd  ^1  ht  cgtploytd  tn  tht  acqaiamon. 
dtaiga.  snd  dtvtioptnt  of  all  Ftdtral  ■Htcnisud  dau  proManf  tmmaniL  strvKti.  and 
ka^mmaminnoa  nyiipniim  and  PSDCN  whancvtr  ns  mctite  hosai/  on  CCITT  Btcoamttdsnot  X.23 
(19101  !mr^  Baemm  Dm  Tarminat  Sympmam  fDTE)  ani  Dm  OreathT  rmmaunp  Eampmcnt  fDCE) 
M  Tarminak  Oparaiiap  in  tka  Raekrt  kiaJa  an  RakBe  Satm^  it  rtqwrtd.  Btfimd  to  htlow  m  CCIfT 
>ii^titadni8t  XU  Bn^nntadanoa  X.29.  or  X29. 

InpItSMMNBfttti  Tht  ytommaa  of  this  jctti  itaodtrd  art  tfthcttvt  iaty  A  1993.  Any  appikabit  aqaipmtni 
or  aarviet  ordtrtd  on  or  afttr  tht  affacn\  t  dait.  or  procartmtni  action  for  which  tolktunon  dooiitnu 
hnwt  not  bntn  iHnod  hy  thni  data,  twai  coni'ora  to  tht  provikont  of  this  nandard  anltat  a  waivtr  hm  bctn 
franitd  in  accordanct  wnh  tht  proendom  drnnbnd  htiow. 
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This  joint  sitndard  sIiaII  be  reviewed  by  the  Institute  for  Computer  Sciences  ind  Technology,  Nttional 
Bureau  of  Standards  and  the  Office  of  the  Manager.  National  Communications  System,  within  five  years 
after  its  effective  date.  This  review  shall  take  into  account  technological  trends  and  other  factors  to 
determine  if  the  joint  standard  should  be  affirmed,  revised,  or  withdrawn. 

Spedficatioiis:  This  joint  standard  adopts  a  subset,  identified  below,  of  the  International  Telegraph  and 

Telephone  Consultative  Committee's  Recommendation  X,25.  _ 

(a)  At  the  physical  level,  the  proviaons  of  Section  !  of  CCll'I  Recommendation  X,25  shall  be  used. 
As  a  minimum,  networks  shall  support  dedicated  circuit  access;  other  types  of  access  (e.g.,  through  the 
general  switched  telephone  network)  may  also  be  offered. 

Cenr  Recommendation  X.l  standardizes  dau  signalling  rates  of  14,  4.8,  9.6.  and  48  kbits/s  for 
packet  mode  interfaces.  At  a  minimum,  networks  shall  suppon  the  synchronous  data  signalling  rates  of  2.4, 
4.8.  and  9.6  kbits/s  full  duplex;  other  speeds  (e.g.,  19.2  kbits/s)  may  also  be  offered.  The  48  kbits/s  rate  need 
not  be  supported  in  those  locations  where  it  is  not  available;  56  kbits/s  is  recommended  in  its  place  (sec 
American  National  Standard  X3.36.1975  and  related  documents  referenced  above).  The  term  “user  class  of 
service”  used  .in  X.25  refers  to  the  data  signalling  rate  of  DTE/DCE  interface. 

In  accordance  with  CCITT  Recommendation  X.25.  networks  shall  provide  one  or  more  of  the 

following  interface  options: 

i.  CCITT  Recommendation  X.21; 

ii.  ElA  RS.232.C,  which  is  essentially  equivalent  to  one  of  the  options  in  CCITT 
Recommendation  X.21bis; 

iii.  CCITT  Recommendation  X.21bts  option  that  is  equivalent  to  RS449  using  only  the  EIA 
RS423A  unbalanced  electrical  characteristics. 

Interworking  between  ElA  RS<232>C  wi  one  side  of  the  interface  and  RS«449  on  the  other  side 
is  permitted  in  accordance  with  ElA  Industrial  Electronics  Bulletin  Number  12.  Where  interworking  with 
RS-232-C  equipmau  is  not  required,  the  provisions  described  below  employing  RS-449  with  the  RS422A 
electrical  characteristics  may  opdcnaily  be  employed  at  ngnaUing  rates  below  48  kbit/s. 

Networics  which  support  48  or  56  kbits ^s  data  signalling  rates  shall  provide  one  or  more  of  the 
foUowmg  interface  options: 

i.  cenr  Recommendation  X.21; 

u.  cerrr  Recommendation  X.21bis  option  that  specifies  CCITT  Recommendation  V .35;  or 
ill  CCITT  Recommendation  X.2lbis  option  that  specifies  CCITT  Recommendation  V.36 
which  is  equivalent  to  ElA  RS-*49. 

NOTE;  Current  study  in  national  and  international  standards  groups  may  result  in  the  development  of 
additional  physical  interfaces.  Each  such  physical  interface  will  be  evaluated  for  incluiion  in  this  joint 
s'jndard.  If  there  are  significant  savings,  one  physical  interface  may  be  selected  as  the  future  mandatory 

physical  interface.  .  .  u 

NOTE:  DTE  purchasers  and  designers  should  determine  which  physical  interfacefs)  is  provided  by 

the  associated  DCE(s). 

(b)  Only  the  LAPS  link  level  procedures  shall  be  used. 

NOTE:  These  procedures  are  a  subset  of  those  described  in  FIPS  PUB  71  and  Federal  Standard 
1003A  and  correspond  to  FIPS  PUB  78  recommended  class  B.  This  subset  U  identified  as  follows: 

i.  l.j«V  configuration;  two  combined  stations  on  a  pomt»to-point  link. 
iL  Off*  of  procedures:  balanced  asynchronous  (BA)  with  options  two  and  eight.  The  RSET 
command  shall  not  be  used.  (RSET  is  found  in  option  U  of  the  FIPS  PUB  71.  RSET  is  pan  of  the  basic 
repertoire  in  Federal  Standard  lv?)3A:  option  11  of  Federal  Standard  1W3A  deletes  the  RSET  command. 
!4ow  that  RSET  is  wf  pan  of  C  CnT  Recommendation  X.25.) 

ill.  Two-way  simultaneous  operation  shall  be  employed. 

:v.  The  smallest  Nl,  (the  number  of  bits  in  an  information  frame  excluding  flags  and 

zero  bit  insertion  for  transparency),  which  shall  be  supponed  shall  be  164  octets  (the  maximum  length  of 
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fast  select  call  setup  packet).  If  a  DTE  neither  transmits,  nor  receives  for  processing  by  higher  level 
functionality  fast  select  packets,  an  N1  as  small  as  135  octets  may  be  supported  by  the  DTE. 

V.  The  address  of  the  combined  station  provided  by  the  network  shall  be  lOOOOOOO;  the  address 
of  the  other  combined  station  shall  be  11000000;  where  the  left-hand  bit  is  the  least  significant  bit  (bit 
number  1}  and  shall  be  transmitted  first  This  convention  is  consistent  with  the  provisions  of  FIPS  71  and 
Federal  Standard  1003A. 

vi.  The  FCS  shall  be  a  16-bit  sequence  as  indicated  in  Section  2.2.7.  DTE/DCE  may  also 
employ  the  32-bit  FCS  as  indicated  in  FIPS  PUB  71  (revised)  and  FED-STD  1003A.  DTE/DCE  equipment 
using  the  32-bit  FCS  shall  be  able  to  also  operate  with  the  16-bit  FCS.  The  smallest  N1  shall  be  166  octets 
when  the  32-bit  FCS  is  used.  If  a  DTE  neither  transmits,  nor  receives  for  processing  by  higher  level 
functionality  fast  select  packets,  an  N1  as  small  as  137  octets  may  be  supported  by  the  DTE  when  the  32-bit 
FCS  is  used. 

NOTE:  FIPS  PUB  78  provides  a  detailed  discussion  of  the  relative  merits  of  the  16-bit  and  32-bit 
FCS. 

vii.  The  frame  reject  information  field  shall  be  padded  with  4  zero  bits  in  bit  positions  21 
through  24  of  the  information  tield  to  provide  a  length  of  three  octets. 

viii.  It  is  required  that  all  implementations  be  capable  of  operating  with  Kml;  optionally,  values 
of  1  to  6  are  permissible  with  modulo  8  operation  and  values  1  to  127  are  permissible  with  modulo  128 
operation. 

NOTE:  DTE  purchasen  and  designers  should  determine  that  values  of  k  other  than  7  are  supponed 
by  the  associated  DCE(s). 

(c)  The  user  data  field  of  packets  shall  be  an  integral  number  of  octets.  If  a  packet  U  received  which 
shows  a  user  dau  field  not  equal  to  an  integral  number  of  octets,  the  receiving  DTE/DCE  shall  follow  the 
packet  level  procedures  for  processing  a  packet  type  which  is  too  long.  A  new  diagnostic  code,  ‘'non-octet 
aligned  packet,"  consistent  with  the  Data  Communications---X,2^  Packtt  Layar  Sptcification  for  Data 
Tirminai  Equipmmi  ISO  DP  8208,  November  8,  1982,  is  recommended  as  #82. 

(d)  The  reject  packet  shall  not  be  used. 

(e)  All  DCE  restart  confirmation,  DCE  reset  confirmation,  and  OCE  clear  confirmation  packeu  shall 
be  interpreted  by  the  D'FE  as  having  local  significance  only. 

(0  The  D^it  shall  be  implemented  by  all  networks-  DTE’s  need  not  employ  the  D-bit  procedures 
when  transmitting  to  the  network,  but  no  DTE  shall  reject  incoming  packets  with  the  D*bit  set  to  I  or  0  as 
having  this  bit  in  error  unless  the  receiving  DTE  knows  the  remote  DTE  has  not  implemented  the  D-bit 
procedure;  in  this  case,  the  receipt  of  a  D-bit  set  to  1  may  be  treated  by  the  receiving  DTE  as  an  error 
condition. 

(g)  The  selection  of  logical  channel  number  for  new  virtual  calls  shall  follow  the  procedures 
suggested  in  Section  4.1.2  Note  2,  Annex  A  Note  S,  and  Annex  A  Note  6,  of  ihe  CCITT  Recommendation 
X.25. 

(h)  It  is  required  that  all  implementations  be  capable  of  operating  with  packet  sequence  numbering 
modulo  8;  optionally,  implemenutions  of  packet  sequence  numbering  modulo  12S  are  alsc  permitted. 

NOTE:  DTE  purchasers  and  deiignen  should  determine  if  the  associated  DC£(s)  suppon  packet 
sequence  numbering  modulo  128. 

(i)  All  DTE's  and  DCE's  shall  foUow  the  flow  control  principles  outlined  in  the  first  two  sentences  of 
the  first  paragraph  of  Section  4.4. 1.3  of  CCITT  Recommendation  X.25. 

(j)  The  alternative  procedure  for  passing  packets  containing  a  P(S)  that  is  out  of  sequence  but  within 
the  window  as  desenbed  in  the  third  paragraph  of  Section  4.4. 1.3  of  CCITT  Recommendation  X.25  shall 
not  be  used. 

tk)  The  second  sentence  of  Section  4.4. 1.4  Note  2  shall  not  apply.  This  sentence  permits  networks  to 
defer  updating  the  window  for  data  packets  with  D»0.  and  sent  within  the  window  but  before  a  data 
packet  with  D»  1.  until  the  network  receives  a  corresponding  P(R)  for  the  packet  with  Die  1. 
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(l)  The  resetting  cause  field  of  a  reset  request  packet  shall  be  set  to  zero.  If  a  reset  request  is  received 
with  a  non>zero  resetting  cause  field,  the  packet  shall  be  discarded.  The  network  shall  then  initiate  the 
resetting  procedure  with  the  resetting  cause  field  indicating  local/remote  procedure  error. 

(m)  The  clearing  cause  field  of  a  clear  request  packet  shall  be  set  to  zero.  If  a  clear  request  packet  is 
received  with  a  non>zero  clearing  cause  field,  the  packet  shall  be  discarded.  The  network  shall  then  initiate 
the  clearing  procedure  with  the  clearing  cause  field  indicating  local/remote  procedure  error. 

(n)  The  restarting  cause  field  of  a  restart  request  packet  shall  be  set  to  zero.  If  a  restart  request  packet 
is  received  with  a  non>zero  restart  cause  field,  the  restart  request  packet  shall  be  discarded  without,  further 
action.  Optionally,  the  DCE  may  generate  a  diagnostic  packet  with  a  recommended  diagnostic  code  #81 
(improper  cause  code  from  DTE),  which  is  consistent  with  the  Data  Communication— X.25  Packet  Layer 
Specification  for  Data  Terminal  Equipment,  ISO  DP  8208,  November  8,  1982. 

(o)  A  diagnostic  code  shall  be  provided  in  all  clear  request,  reset  request,  and  restart  request  packets 
in  accordance  with  thr  codes  listed  in  Annex  E  of  CCITT  Recommendation  X.25  whenever  they  apply; 
non*assigned  codings  in  X.25  may  be  used  for  events  not  listed  in  X.25  within  the  period  of  24  months  after 
the  effective  date  of  this  standard.  Prior  to  the  end  of  this  24  month  period,  this  standard  will  be  reviewed 
by  NBS  to  determine  whether  the  standard  should  be  revised  to  incorporate  a  different  table.  After  this 
revision,  codes  not  specifically  listed  shall  not  be  used. 

(p)  A  generic  diagnostic  code  shall  not  be  used  when  a  more  specific  diagnostic  code  is  known  to  be 
applicable. 

(q)  The  network  diagnostic  codes  shall  be  used  in  accordance  with  the  codes  listed  in  Annex  E  of 
CCITT  Recommendation  X.25  whenever  they  apply;  non-assigned  codings  in  X.25  may  be  used  for  events 
not  listed  in  X.25  within  the  period  of  24  months  after  the  effective  date  of  this  standard.  Prior  to  the  end  of 
this  24  month  period,  this  standard  will  be  reviewed  by  NBS  to  determine  whether  the  standard  should  be 
revised  to  incorporate  a  different  table.  After  this  revision,  network  diagnostic  codes  not  specifically  listed 
shall  not  be  used. 

(r)  The  network  shall  consider  the  receipt  of  a  DTE  interrupt  packet  before  a  previous  DTE 
interrupt  packet  has  beer  confirmed  as  an  error,  and  shall  execute  the  error  procedure  described  in  Annex 
C,  Table  C-4,0<.25  and  the  corresponding  note  2. 

(s)  The  timeouts  and  time  limits  specified  in  Annex  D  shall  be  observed  by  all  DTE  and  DCE 
equipment.  T21  shall  not  be  less  than  the  value  given  in  uble  D-2/X.25.  The  preferred  actions  listed  in  uble 
D*2/X.25  shall:  be  followed. 

(t)  When  the  link  level  procedures  enter  the  logically  disconnected  sute,  the  associated  packet  level 
procedures  shall  clear  all  virtual  calls  and  reset  all  permanent  virtual  circuits  and  datagram  logical  channels. 
When  the  link  level  procedures  reenter  the  information  transfer  slate,  the  associated  packet  level  procedures 
shall  execute  the  restart  procedure.  The  terms  ‘'logically  disconnected  state"  and  “information  transfer 
state"  are  used  as  defined  in  American  National  Standard  X3. 66-1979  (referenced  above).  Link  level 
procedures  enter  the  logically  disconnected  state  when  a  DISC  command  is  sent  and  a  UA  response  is 
received,  for  example.  The  link  level  procedure  shall  also  be  considered  to  be  m  the  logically  dtsconnected 
state  after  N2  (re)transmissions  of  SABM  or  DISC,  where  N2  is  as  defined  in  CCITT  Recommendation 
X.25.  The  logically  disconnected  sute  is  not  assumed  after  N2  (re)transmissions  of  other  types  of  frames. 

(u)  If  a  resurt  request  packet  is  received  m  sute  rl  which  exceeds  the  maximum  permitted  length,  the 
DCE  shall  discard  the  restart  request  packet  without  further  action.  Optionally,  the  DCE  may  generate  a 
diagnostic  packet  with  diagnostic  code  (packet  too  long). 

(v)  In  the  event  that  a  facility  code  appears  more  than  once  in  a  facility  field,  the  receiving  DTE 
detecting  this  condition  should  treat  the  last  appearance  of  the  particular  code  as  if  it  were  the  only 
appearance  of  that  code. 

(w)  All  networkv  shall  supply  diagnostic  packets  when  their  use  is  suggested  in  CCITT 
Recommendation  X.25.  No  DTE  shall  reject  diagnostic  packets  as  errors 

(x)  In  Section  6.5.1.  the  second  paragraph,  the  last  phra.se.  "and  is  set  to  0  m  all  other  packets",  shall 
he  interpreted  that  the  Qualifier  bn  is  set  to  0  m  all  other  packets  except  dau  packets.  For  the  case  of  data 
packets,  the  Qualifier  hit  is  set  to  0  or  1  as  indicated  in  Section  4  3  6  of  CCITT  Recommendation  X.23. 
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(y)  The  list  of  user  facilities  for  packet-switched  data  networks,  extracted  from  CCITT 
Recommendation  X.2,  is  given  below.  These  facilities  are  described  in  Section  7  of  CCITT 
Recommendation  X.25.  The  following  funher  constraints  apply; 

i.  Networks  shall  provide  the  facilities  designated  as  essential  '*£”  below. 

ii.  Networks  shall  also  implement  the  Fast  Select  and  Fast  Select  Acceptance  facilities  to 
faciliute  more  efficient  operation  in  conveying  higher  layer  protocol  information  or  user  data  during  call 
establishment.  DTE's  need  not  employ  fast  select  packets  when  transmitting  to  the  network,  but  all  DTE*s 
associated  with  the  higher  level  functionality  which  allows  response  to  a  fast  select  packet  must  be  able  to 
accept  incoming  fast  select  packets. 

iii.  The  packet  retransmission  facility  shall  not  be  used. 

iv.  All  DTE’s  which  employ  any  of  the  facilities  labelled  as  additional  '*A”  below  (e.xcept  Fast 
Select  and  Fast  Select  Acceptance)  shall  also  be  capable  of  operating  without  employing  any  A  facilities 
(except  Fast  Select  and  Fast  Select  Acceptance). 

V.  The  throughput  class  value  of  4d,(XX}  bits/s  may  be  interpreted  as  56,(XX}  bits/s  in  those 
locations  where  56,(XX}  bits/s  access  is  used. 
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Facilities  of  packet-switehed  data  networks: 


User  Facility 

Optionil  user  facilities  assigned 
for  an  agreed  contractual  period; 

Extended  packet  sequence  numbering 

V**»*«^ 

Non-Standard  default  window  sizes 
Non-standard  default  packet  sizes 
16,  31  64.  256.  512,  1024 
Default  throughput  class  assignment 
Flow  control  parameter  negotiation 
Throughput  class  ncgoution 
Packet  retransmission 
Incoming  calls  barred 
Outgoing  calls  barred 
One-way  logical  channel  outgoing 
One-way  logical  channel  incoming 
Closed  user  group 
Closed  user  group  with  outgoing 
access 

Oosed  user  group  with  incoming 
access 

Incoming  calls  barred  within  a 
closed  user  group 
Qutgomg  caiis  barred  within  a 
closed  user  group 
Bilaienl  closed  user  group 
Bilateral  closed  user  group  with 
outgoing  access 
Reverse  charging  acceptance 
Fut  select  acceptance 
Datagram  queue  length  selection* 
Daugram  service  signal  logical 
channel* 

Datagram  non-delivery  indication* 
Datagram  delivery  confirmation* 
D-bit  modification 

Optional  user  jiMlities  revested 
by  the  DTE  on  a  per  call  baas 

Closed  user  group  selection 
Bilateral  closed  user  group  selection 
Reverse  charging 
RPOa  selection 

Flow  control  parameter  negotiation 
Fast  select 

Throughput  class  negotiation 
Abbreviated  address  calling 
Daugram  non-delivery  indicadon 
Daugram  delivery  confirmation 


VC  PVC  DG* 


A 

A 

A* 

A 

A 

A* 

A 

A 

A 

A 

A- 

E 

- 

- 

E 

- 

- 

A*** 

A*** 

A*** 

E 

E* 

E 

- 

E* 

E 

- 

A* 

A 

» 

A* 

E 

- 

E* 

A 

- 

A* 

A 

- 

A* 

A 

- 

A* 

A 

A* 

A 

- 

A* 

A 

A* 

A 

- 

A* 

A** 

- 

- 

- 

- 

A* 

A* 

• 

E* 

• 

E* 

A 

A 

- 

E 

- 

E^ 

A 

A* 

A 

- 

A* 

A 

- 

A* 

E 

- 

- 

A** 

- 

- 

E 

- 

- 

FS 


A* 

E* 

E* 


NOTE:  Detailed  explanations  of  these  facilities  are  provided  in  CCriT  Recommendauon  X.25. 
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LEGEND: 

E  *  An  tfsweniial  user  facility  to  be  offered  by  ail  networks. 

A  »  An  additional  user  facility  which  may  be  offered  by  certain  networks. 

FS  *  Further  study  is  required.  This  standard  will  be  modified  when  this  study  is  complete. 

-  *  Not  applicable. 

DO  *  Applicable  when  the  datagram  service  is  being  used.* 

VC  »  Applicable  when  the  virtual  call  service  is  being  used. 

PVC  «  Applicable  when  the  permanent  virtual  circuit  service  is  being  used. 

•  -  The  datagram  service  and  its  related  facilities  may  be  used  only  when: 

-  there  is  to  be  a  one-way  transfer  of  information  which  does  not  require  recovery  at  the  network 
layer,  and. 

-  a  response  to  this  transfer  of  information  is  not  required  at  the  network  layer. 

NOTES:  1.  At  the  present  time,  the  transfer  of  datagram  packets  across  international  borders  through 
public  packet-switching  networks  is  not  permitted. 

2.  DCE's  are  not  required  to  provide  datagram  service.  DTE’s  are  not  required  to  generate  or  accept 
datagrams  and  datagram-related  packets. 

••  -  Fast  select  shall  be  provided  by  all  DCE*s.  All  DTE*s  associated  with  the  higher  level 
functionality  which  allows  response  to  a  fast  select  packet  must  be  capable  of  accepting  incoming  fast 
select  packets,  but  need  not  generate  fast  select  packets. 

**”  The  packet  retransmission  facilities  shall  not  be  used. 
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(z)  The  list  of  the  applictble  call  progress  signals,  extnaed  from  CCITT  Recommendation  X.96,  is 
given  below.  These  signal  definitions  apply  to  the  cause  codes  specified  in  CCITT  Recommendation  X.2S. 
The  related  circumstances  giving  rise  to  each  call  progress  signal  is  also  defined  in  table  1  below.  The 
significance  of  categories  indicates  broadly  the  type  of  action  expected  of  the  DTE  receiving  the  signal: 


Category  Significance 


A 

B 

ClandC2 


D1  and  D2 


Cl  and  D1 
aandD2 


Requested  action  confirmed  by  network. 

Call  cleared  because  the  procedure  is  complete. 

Call  cleared.  The  calling  DTE  should  call  again  soon;  the  next  attempt  may  be 
successful.  However,  after  a  number  of  unsuccessful  call  attempts  with  the  same 
response,  the  cause  could  be  assumed  to  be  in  Category  D1  or  DI  The  interval  between 
successive  attemptt  and  the  number  of  maximum  attempts  will  depend  on  a  number  of 
circumstances  induding: 


-  nature  of  the  call  progress  signal 

-  users*  traffic  patmm 

-  tariffs 

-  possible  regulations  by  the  network  provider. 

OR 

Reset  The  DTE  may  continue  to  transmit  data 
recognizing  that  dam  loss  may  have  occurred. 

Call  cleared.  The  calling  DTE  should  take  other  action  to  clarify  when  the  call 
attempt  might  be  successful. 

OR 

Reset  (for  permanent  virtual  circuit  only). 

The  DTE  should  cease  dam  transmission  and  take  other  action  as  appropriate. 
Due  to  subscriber  condition. 

Due  to  network  condition. 


The  sequence  of  call  progreu  signals  in  table  I  implies,  for  Categories  C  and  D.  the  order  of  call  iet*up 
processing  by  the  network.  In  general,  the  DTE  can  assume,  on  receiving  a  call  progren  signal,  that  no 
condition  higher  up  in  the  table  is  present.  Network  congestion  is  an  exception  to  this  general  rule.  The 
actual  coding  of  call  progress  signals  does  not  necessarily  reflect  this  sequence. 

Users  and  DTE  manufacturers  are  warned  to  make  due  allowance  to  possible  later  extensions  to  thb  table 
by  providing  appropriate  fall-back  routines  for  unexpected  signals. 


C-ll 


1-519 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


FIPS  PUB  100 


Taklt  1 


CaUfnpm 

SifMi 

Catifoiy 

Ddivtry 

confirmuioii 

The  datifraffl  haa  beta 
accepted  by  (be  dewtnarioa  DTE 

A 

Local  procadttrc 
tnof 

A  procedure  error  eauMd  by  the  DTE 
d  detected  by  the  DCS  at  the  local 

DTE/DCE  iaterface. 

Cl 

Network 

comnow 

A  coodittoe  eaiita  ie  the  network 
sechai: 

1)  tespore^  network  conpeition 

2)  temporary  fuilt  condidon  withia 
the  network)  tneindinf  proendnre  error 
wnhtn  a  network  or  an  mieniatiooal  link. 

Cl 

Iti 

isl 

A  (heiUty  reqaeaied  by  the  ealUttf 

DTE  d  detected  aa  invalid  by  the  DCE 
at  the  local  DTE/DCE  tntertee. 

Poaaible  ranaona  include; 

-  requaat  fbr  a  Cactltty  which  haa  not 
been  subeenbed  to  by  the  DTE 

-  requeat  for  a  faci^  which  d  not 
available  in  the  local  network: 

«  raqumt  for  a  raetUty  which  haa  not 
been  racofnuad  aa  valid  by  the  local  DCE 

DtorD2 

RPOA  OM 
of  order 

The  RPOA  nominated  by  the  calling  DTE  d 
unable  to  forward  the  call 

D2 

Not 

obteieabte 

The  caUad  DTE  addma  d 
out  of  tN  numbanwg  plan  or  not 
aaaignad  to  any  DTE 

Dl 

AccMbarrad 

The  calliAg  DTE  d  wn  penniwed 
the  tfonnaction  m  the  called  DTE 

PtMaiWe  (uaaona  NKimlet 

•  unaathoriiad  accaaa  between  the  calling 

DTE  and  the  caldd  DTE 

•  incompatible  cloaed  uaer  group- 

Dl 

Reverie  cherfmf 

iHxnrfNeiice  nui 
wlwcrdied 

The  walled  DTE  haa  not  lubacnhad 
h»  the  reveiae  charging  ucv'CfNance 
faciiiiy. 

Dl 

F«m  wlevf 
eccefNaiKe  me 
wthcnhed 

The  called  DTE  haa  nut  tulMcnhed 
lo  the  Ide  wiect  JcceiManct 
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WabirK  Waiver  of  this  standtrd  is  required  when  an  interface  based  on  CCITT  Recommendation  X.25 
(1910)  b  to  be  employed  and  has  either  one  of  the  following  conditions:  1)  The  interface  has  options  that 
ire  not  permitted  by  this  standard:  2)  The  interface  docs  not  implement  alt  options  mandated  by  this 
standard. 

Heads  of  afeneics  denring  a  waiver  from  the  requiremenu  stated  in  this  standard,  so  as  to  acquire 
applicable  equipment  or  service  not  conforming  to  this  standard,  shall  submit  a  request  for  waiver  to  the 
Administrator.  General  Services  Administration,  for  review  and  approval.  Approval  will  be  granted  if,  in 
the  judgment  of  the  Administrator  after  consulution  with  the  Assistant  Secretary  of  Commerce  for 
Productivity.  Technology  and  Innovation,  based  on  all  available  informadon  including  that  provided  in  the 
waiver  requests,  a  major  adverse  economic  or  operational  impact  would  occur  through  conformance  with 
this  itandaid. 

A  request  for  waiver  shall  include  a  justification  for  the  waiver,  including  a  description  and  discussion  of 
the  adverse  economic  or  operational  impact  that  would  result  from  conforming  to  this  standard  as 
compared  to  the  alternative  for  which  the  waiver  is  requested.  ICST  and  NCS  will  provide  technical 
assistance,  as  required,  to  GSA. 

Where  to  Ohtala  Cepiee;  Copies  of  this  publicadon  are  for  sale  by  the  National  Technical  Information 
Service.  U.S.  Depenment  of  Commerce,  Sphngfteld.  Va  22161.  When  ordering,  refer  to  Federal 
Information  Proc^ng  Standards  Publicaiion  100  (FTPS-PUB«I00)/Federal  Standard  1041  (FED*STD 
1041).  and  title.  When  raicroRche  is  desired,  this  should  be  spedAed.  Payment  may  be  made  by  check, 
money  order,  purchase  order,  credit  card,  or  deposit  account. 

The  cerrr  x.25  tpcdncaiicns  upon  which  this  publicacioo  b  based  may  also  be  obtained  from  NTIS. 
Specify  PBI24t77b6;  the  cost  b  SSO.  telephone  (703)  4174650. 
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Status  Of  This  Memo 

The  reader  should  be  aware  of  several  things  in  regard  to  what  the 
present  document  is  up  to.  First  and  foremost,  IT  IS  A  PROPOSAL  FOR 
A  STANDARD,  NOT  A  STANDARD  ITSELF.  Next,  it  assumes  that  the 
separate  document,  RFC  928,  which  is  an  introduction  to  the  present 
document,  has  been  read  before  it  is.  Next,  it  should  be  understood 
that  ” final  cut”  over  this  version  of  the  document  has  been  exercised 
by  the  author  of  RFC  928,  not  by  the  primary  author  of  the  present 
document,  so  any  readers  bothered  by  style  considerations  should  feel 
free  to  blame  the  former,  who's  used  to  it,  rather  than  the  latter, 
who  may  well  be  guiltless.  (Editing  at  a  distance  finally  become  too 
hard  to  manage,  so  if  I'm  typing  it  myself  I'm  going  to  fiddle  with 
it  myself  too.  Including,  but  not  limited  to,  sticking  my  own  section 
on  the  Conceptual  Model  in  before  Joel's  words  start,  rather  than 
leaving  it  in  the  Introduction.  rW) 

Finally,  it  should  be  noted  that  this  is  not  a  finished  document. 

That  is,  the  intent  is  eventually  to  supply  appcmdices  for  all  of  the 
protocol  offloadings,  describing  their  uses  of  protocol  idiosyncratic 
parameters  and  even  their  interpretations  of  the  standard  per -command 
parameters,  but  in  order  to  get  what  we've  got  into  circulation  wo 
haven't  waited  until  all  such  appendices  have  been  written  up.  (We 
do  have  notes  on  how  to  handle  FTP,  e.g.,  and  UDP  will  be  pretty 
straightforward,  but  getting  them  ready  would  have  delayed  things 
into  still  another  calendar  year,  which  would  have  been  very  annoying 
...  not  to  say  embarrassing.)  For  that  matter,  it's  not  even  a 
finished  document  with  respect  to  what  is  hero.  Not  only  is  it  our 
statnd  intention  to  revise  the  protocol  based  upon  ioplementation 
experience  gained  from  volunteer  test  implementations,  but  it's  also 
the  case  that  it  hasn't  proven  feasible  to  iron  out  all  known 
wrinkles  in  what  is  being  presented.  For  example,  the  response  codes 
almost  certainly  need  clarification  and  expansion,  and  at  least  one 
of  us  doesn't  think  mandatory  initial  parameters  need  control  flags. 
However,  to  try  too  hard  for  polish  would  be  to  stay  in  subcommittee 
for  the  better  part  of  forever,  so  what  you  see  is  what  we've  got, 
but  certainly  isn't  meant  to  be  what  you  or  we  are  stuck  with. 

This  RFC  suggests  a  proposed  protocol  for  the  ARPA- Internet 
community,  and  requests  discussion  and  suggestions  for  improvements . 
Distribution  of  this  memo  is  unlimited. 
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Conceptual  Model 

There  are  two  fundamental  motivations  for  doing  outboard  processing. 
One  is  to  conserve  the  Hosts'  resources  (CPU  cycles  and  memory)  in  a 
resource  sharing  interconqputer  network,  by  offloading  as  much  of  the 
required  networking  software  from  the  Hosts  to  Outboard  Processing 
Environments  (or  "Network  Front-Ends")  as  possible.  The  other  is  to 
facilitate  procurement  of  Inplomentations  of  the  various 
intercomputer  networking  protocols  for  the  several  types  of  Host  in 
play  in  a  typical  heterogeneous  interconputer  network,  by  employing 
common  implementations  in  the  OPE.  A  third  motivation,  of  basing  a 
network  security  approach  on  trusted  mandatory  OPEs,  will  not  be 
dealt  with  here,  but  is  at  least  worthy  of  mention. 

Neither  motivation  should  be  allowed  to  detract  from  the  underlying, 
assumed  desire  to  perform  true  interconputer  networking,  however. 
Therefore,  it  is  further  assumed  that  OPEs  will  be  attached  to  Hosts 
via  a  flexible  attachment  strategy,  as  described  in  [1]  .  That  is,  at 
the  software  level  an  explicit  Host-Front  End  Protocol  (H-FP)  will  be 
employed  between  Hosts  and  OPEs,  rather  than  having  OPEs  emulate 
devices  or  device  controllers  already  "known"  to  Host  operating 
systems  (in  order  to  avoid  introducing  new  code  into  the  Host)  . 

For  reasons  discussed  in  the  Introduction,  an  H-FP  resolves  into 
three  layers.  The  Link  layer  fsiables  the  exchange  of  bits  between 
Host  and  OPE.  The  Channel  layer  enables  the  bit  streams  to  be 
demultiplexed  and  flow  controlled  (both  the  Channel  and  Link  layers 
may  use  preexisting  per -Host  mechanizations,  it  should  be  recalled) . 
The  Command  (or  "Service  Access")  layer  is  our  primary  concern  at 
present.  It  serves  as  the  distributed  processing  mechanism  which 
allows  processes  on  Hosts  to  manipulate  protocol  Interpreters  (Pis) 
in  OPEs  on  their  behalf;  for  convenience,  it  will  be  referred  to  as 
"the  H-FP"  here.  (It  should  be  noted  that  the  Link  and  Channel 
layers  may  be  viewed  as  rou^ly  equivalent  to  the  inboard  processing 
investment  for  a  Host -comm  subnet  processor  PI  and  device  driver,  so 
in  practical  terms  the  savings  of  resources  achieved  by  outboard 
processing  come  from  making  the  H-FP  "smaller"  than  the  inboard 
ioplementations  of  the  protocols  it  allows  to  be  offloaded.) 

The  crucial  property  of  the  H-F?  conceptually  is  that  it  stands  as 
the  interface  between  a  (Host)  process  arxi  a  PI  (which  is  actually 
outboard) .  Usually,  the  model  is  that  of  a  closed  subroutine 
interface,  slthou^  in  some  cases  an  interprocess  communication 
mechanism  model  must  be  appealed  to.  That  is,  the  interactions 
between  cooperating  K-FP  Pis  in  some  sense  mimic  subroutine  or  IPC 
calls,  from  the  perspective  of  Host  processes  calling  upon  their  own 
H-FP  Pis.  which  in  turn  are  of  course  interfacing  via  just  such 
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mechanisms  themselves.  Another  way  of  putting  it  is  that  **if  the 
protocols  were  inboard/’  the  processes  invoking  H-FP  wouldn’t  know 
the  difference.  H-FP,  then,  may  be  viewed  as  a  roundabout  way  of 
lotting  Host  processes  "get  at"  various  Pis. 

Naturally,  the  mechanization  of  the  desired  concept  cannot  be 
particularly  literal.  After  all,  the  Hosts  and  the  OPEs  are 
different  processors,  so  we’re  not  envisioning  a  passing  tiirou^  of 
parameters  in  an  exact  fashion.  However,  in  broad  terms  the  model  is 
just  that  of  a  sonewhat  funny  interface  between  a  process  and  a  PI . 
(This  should  not  be  construed  as  ruling  out  the  occurrence  of  events 
which  prompt  the  OPE  to  initiate  an  exchange  of  coanands  with  the 
Host,  thou^;  see  the  Introduction  for  more  on  the  topic  of 
"Symmetric  B^ins.") 

Interaction  Discipline 

The  interaction  between  the  Host  and  the  OPE  must  be  capable  of 
providing  a  suitable  interface  between  processes  (or  protocol 
interpreters)  in  the  Host  and  the  off-loaded  prot;ocol  interpreters  in 
tlie  OPE.  This  interaction  must  not,  however,  burden  the  Host  more 
heavily  than  %/ould  have  resulted  from  stjpporting  the  protocols 
inboard,  lest  the  advantage  of  using  an  OPE  be  overridden. 

Channel  Level  Interaction 

As  stated  elsewhere,  the  Channel  level  protocol  (isplicitly  In 
c«i junction  with  the  Link  level)  provides  two  major  functions.  These 
are  demultiplexing  the  traffic  from  the  Link  level  into  distinct  data 
streams,  and  providing  flow  control  between  the  Host  and  the  OPE  on  a 
per  stream  basis.  These  hold  even  if  the  Host-OPE  attachment  is  DMA. 

The  data  streams  between  the  Host  and  the  OPE  are  bidirectional.  In 
this  document,  the  basic  unit  of  data  transferred  by  the  Channel 
level  is  referred  to  as  a  "chunk".  The  primary  motivation  for  this 
terminology  is  that  the  H-FP  permits  the  Channel  level  to  be  one  of 
several  possible  protocols,  each  with  its  own  terminology.  For 
example,  a  chunk  on  an  X.2$  Channel  would  be  a  packet,  while  a  chunk 
on  the  DTI  H-FP  channel  would  be  a  message.  While  the  Command  level 
is,  in  a  sense,  "more  effici«tt"  when  the  chunk  size  is  permitted  to 
be  large,  the  flexibility  penaitted  In  the  choice  of  protocols  at  the 
Channel  level  precludes  ar^  assumptions  about  the  chunk  size. 

Each  data  stream  Is  fully  asynchronous .  A  Channel  protocol  user  can 
send  data  at  any  time,  once  the  channel  has  been  properly  opened. 

(The  Command  level’s  logic  may  render  some  actions  meaningless, 
however.)  The  data  transfer  service  provided  by  the  Channel  protocol 
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is  reliable;  this  entails  deli'^ery  In  the  v:orrect  order,  without 
duplication,  and  checked  for  bit  errors.  All  retransmission,  error 
checking,  and  duplicate  detection  Is  provided  ay  this  protocol  In  a 
way  that  Is  transparent  to  the  user.  (If  the  attachment  is  DMA. 
stream  identification  and  chunk  length  must  still  be  provided  for.) 

Ihe  flow  control  at  the  Channel  level  Is  pro/lded  to  prevent  the  OPE 
and  the  Host  from  overloading  each  other's  resources  by  excessive 
transmissions.  In  general.  ^Is  flow  control  should  not  directly 
affect  the  outbo;ird  protocol  Interpreters'  operation.  On  the  other 
had.  this  flow  control  has  the  same  effect  as  ejqpllclt  Interface 
events  that  provide  flow  control  between  the  user  and  the  protocol 
Interpreter  (e.g..  the  Allocate  event  of  the  interface  specification 
for  TCP  found  in  MIL-STD  1778)  .  Hence,  such  events  do  not  need  to  be 
cofSBunlcated  coqplxcltly  at  the  Coonand  level.  (If  the  attachnent  Is 
DMA.  flow  control  must  still  be  provided  for.) 

Should  Hosts  require  an  OPE  to  be  attached  via  a  Link  Level  that 
furnishes  physical  demultiplexing  (e.g..  a  eroup  of  RS232  ports),  any 
attempt  to  avoid  furnishing  reliability  and  u>qpllclt  flow  control.  Is 
done  at  their  peril;  we  have  not  chosen  to  assist  sucl»  an 
enterprise.  b>it  neither  have  we  precluded  It.  (It  would  certainly 
violate  the  spirit  of  the  thing,  however.) 

Command  Level  Interaction 

The  aj^roach  chosen  for  this  H-FP  Is  to  hast  the  Interaction  or  a 
small  set  of  commands,  saparately  applicable  to  a  given  Channel  Level 
channel.  The  commands  are  sisple.  but  sufficiently  flexible  to  permit 
the  off-loading  of  the  lnterpret<^jrs  of  the  large  number  of  protocols 
at  various  levels  In  the  hierarchy.  This  flexibility  Is  made 
possible  In  part  by  the  slMlar  nature  of  the  Interfaces  to  most 
protocols,  coeblned  with  tie  provision  of  "protocol  idiosyncratic 
parameters".  These  paramators  are  defined  for  each  offloaded  protocol 
Interpreter  in  the  OPE.  The  use  of  such  parameters  doM  not 
coapllcate  the  basic  design  of  the  OPE.  since  It  must  be  customised 
for  each  off-loaded  protocol  anyway,  and  all  that  la  req^red  of  the 
OPE  for  those  parameters  Is  to  pass  them  to  the  off-loaded  protocol 
Interpreter.  Hence,  an  interface  tailored  to  a  particular  protocol 
can  be  .*reated  In  a  stralq^hti orward  and  cost-effective  way. 

The  coanand  dialog  Is  more  or  less  asynchronous .  Commands  can  be 
issued  at  any  particular  zitaa  (except  when  there  Is  a  pending 
command,  which  win  be  dlsinissed  below),  and  there  is  no  need  for 
dummy  traffic  on  a  channel  when  no  commands  are  issued. 

Associated  with  each  coama^.d  Is  a  response.  The  purpose  of  this 
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response  is  to  indicate,  at  some  level  that  depends  in  part  on  the 
particular  protocol  interpreter  that  is  offloaded  to  the  OPE,  whether 
the  command  was  successfully  executed,  and  if  unsuccessful,  the 
reason.  Often,  generating  the  response  involves  interaction  with  the 
protocol  interpreter  before  a  response  can  be  generated. 

When  a  command  is  issued,  the  issuer  must  wait  for  a  response  before 
another  command  is  issued.  The  nature  of  the  communication  between 
the  Host  and  the  OPE  is  thus  a  lock  step  command/response  dialog. 
There  are  two  major  exceptions  to  this  principle,  however.  One 
exertion  is  the'  abrupt  form  of  the  End  command,  which  can  be  issued 
at  any  time  to  cancel  any  previously  issued  commands,  and  indicate 
that  services  are  no  longer  desired.  The  other  exception  is  the 
Signal  command.  Since  a  Signal  is  out-of-band  and  usually  of  high 
inqportance,  forcing  it  to  wait  on  a  response  would  be  undesirable. 
Hence,  a  Signal  command  can  be  issued  while  commands  (other  than 
Signal)  are  pending.  However,  a  Signal  command  sliould  not  be  issued 
before  a  successful  response  to  the  Begin  command  has  been  received. 
Since  it  is  possible  for  more  than  one  command  of  different  types  to 
be  pending  at  one  time,  a  mechanism  to  distinguish  responses  is 
needed.  Since  there  are  never  two  commands  of  the  same  type  pending, 
including  the  command  name  in  the  response  is  sufficient  to  make  this 
distinction . 

A  special  case  command  is  the  Transmit  command.  Details  of  the 
Transmit  command  are  provided  in  the  next  section.  Essentially,  the 
Transmit  command  is  usesd  to  invoke  the  data  transfer  services  of  the 
off-loaded  protocol  (when  issued  by  the  Host)  or  to  indicate  the 
arrival  of  new  data  from  the  network  (when  issued  by  the  OPE)  .  Tne 
natu.*e  of  specific  protocol  interfaces  for  these  events  varies  widely 
between  protocols.  Some  may  block  until  the  data  is  accepted  by  the 
remote  counterpart  (or  ’'peer”)  protocol  interpreter,  while  others  may 
not.  Hence,  there  is  a  special  parameter  which  indicates  the  nature 
of  the  Transmit  command  Interface.  It  can  either  require  that  the 
response  should  be  generated  immediately  after  determining  the 
Transmit  command  is  conplete  and  formed  properly,  or  can  indicate 
that  the  response  should  not  be  generated  until  the  ajipropriate 
interface  event  is  given  by  the  remote  protocol  interpreter.  The 
default  action  for  all  Transmit  commands  can  be  initialized  using  the 
Begin  command  and  changed  using  the  Condition  command.  Also,  the 
default  action  can  be  temporarily  overridden  by  specifying  a 
parameter  with  tlie  Transmit  command.  The  net  result  of  this  mcsclianism 
is  to  allow  the  Host  to  determine  within  reason  just  how  lock-stepped 
transmissions  are  to  be.  (It  is  assumed  that  the  usual  case  will  be 
to  transfer  the  burden  of  buffering  to  the  OPE  by  taking  immediate 
responses,  provided  that  doing  so  "makes  sense"  with  the  particula)* 
offloaded  protocol  in  play.) 
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Some  protocols  provide  a  block- oriented  data  transfer  service  rather 
than  a  stream-oriented  one.  With  such  a  service,  the  data  associated 
with  a  transfer  request  is  viewed  as  an  integral  unit.  For  actual 
network  transmission,  the  protocol  may  permit  these  units  to  be 
groi^jed  or  fragmented.  However,  the  receiving  end  must  deliver  the 
data  in  the  original,  integral  units.  Protocols  that  conform  to  this 
model  include  some  datagram  protocols  such  as  IP  and  UDP,  and  also 
some  connection  protocols  such  as  NBS  TP. 

To  cater  to  these  types  of  protocols,  -t  is  a  convention  that 
commands,  their  parameters,  and  any  associated  data  be  transferred 
between  the  Host  and  the  OPE  in  a  single  chunk.  Any  data  associated 
with  an  H-FP  command  is  viewed  as  an  integral  ur.it  which  is  used  in 
the  corresponding  service  request  given  to  the  outboard  protocol 
interpreter  or  delivered  as  a  complete  unit  to  the  process  in  the 
Host,  Operation  of  stream-oriented  protocols  such  as  TCP  will  not  be 
adversely  affected  by  this  convention. 

To  accommodate  Channel  protocols  that  do  not  provide  for  arbitrarily 
large  chunks,  a  mechanism  at  the  Command  level  is  required  to  permit 
the  linking  of  multiple  chunks  into  a  single  command,  in  order  to 
transfer  the  burden  of  buffering  as  much  as  possible  from  the  Host  to 
the  OPE,  The  facility  proposed  here  would  consist  of  an  indication 
at  the  beginning  of  each  chunk  which  would  distinguish  integral 
commands,  fragments  of  a  command  for  which  more  fragments  are  yet  to 
arrive,  and  the  final  fragment  of  a  command.  The  details  of  this 
mechanism  are  discussed  in  the  section  on  the  syntax  of  commands  and 
responses . 

It  is  a  convention  for  this  H-FP  that  any  data  associated  with  a 
command  must  start  on  a  word  boundary  (as  defined  by  the  local 
system)  .  Consequently,  there  is  a  need  to  provide  padding  within  the 
commands.  Such  padding  is  used  only  to  fill  to  the  next  appropriate 
boundary,  and  has  no  semantic  significance  to  the  command  interpreter 
(i.e.,  two  commands  that  are  identical  except  for  the  amount  of 
padding  should  behave  identically)  .  The  details  of  this  padding  are 
discussed  in  the  section  on  the  syntax  of  commands  and  responses. 
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Syntax  Rules 

At  the  Command  Level,  communication  between  the  Host  and  the  OPE 
takes  the  form  of  commands  and  responses.  A  command  Is  a  request  for 
some  particular  action,  and  the  response  Indicates  the  success  or 
failure  of  performing  the  requested  action. 

All  commands  and  responses  are  coded  In  ASCII  characters.  (Nothing 
precludes  OPEs  from  accepting  EBCDIC  from  Hosts  that  use  it  In  native 
mode,  but  chat  is  not  required.)  These  characters  are  sent  in  some 
way  convenient  for  the  Host,  and  the  OPE  is  sufficiently  flexible  to 
interpret  them.  (l.e.,  OPEs  are  expected  to  accommodate  Host 
idiosyncracies  in  regard  to  such  things  as  use  of  7-bit  ASCII  in  a 
9-bit  field.)  This  approach  offers  several  advantages: 

Adaptabilities  in  most  Hosts:  Most  Hosts  have  the  ability  to 
generate  and  Interpret  ASCII  character  streams.  Hence,  integrating 
H-FP  into  a  Host  will  not  require  difficult  software. 

Script  generation:  Generation  of  test  and  operational  command 
scripts  will  be  simplified,  since  they  will  not  need  to  contain 
special  characters. 

Terminal  Operation:  Using  sinple  command  streams  simplifies  the 
conversion  of  an  OPE  to  a  gen-^ric  virtual  terminal  support  machine. 
This  is  particularly  useful  during  development  and  testing. 

Testing:  Testing  will  not  require  special  hardware  to  Interpret 
commands  and  resp>onses.  A  terminal  or  data  line  analyzer  would  be 
adequate . 

The  specific  format  for  the  commands  and  responses  will  be  discussed 
in  the  sections  that  follow.  In  those  sections,  the  quote  character 
is  used  to  Indicate  strings.  The  symbols  "<"  and  ">"  (referred  to  as 
angle  brackets)  are  usckI  as  meta - characters . 

Syntax  of  Commands 

As  alluded  to  In  the  section  discussing  the  interaction  discipline 
between  the  Host  and  the  OPE,  a  function  is  provided  by  which  a  chunk 
can  be  »jsed  to  carry  either  a  complete  command  or  a  fra^jnent  of  a 
command.  The  mechanism  chosen  to  provide  this  function  cmtalls  use 
of  the  first  character  position  in  the  chunk  as  a  chunk  usage 
identifier.  The  character  “C"  in  the  first  position  indicates  a 
chunk  containing  a  single,  complete  command.  *'F"  in  the  first 
position  indicates  a  chunk  which  is  the  first  part  of  a  multichunk 
command.  ”M“  in  the  first  position  indicates  the  chunk  is  a  middle 
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part  (neither  the  first  nor  the  last  chunk)  of  a  command.  Finally, 

'‘L‘‘  indicates  the  chunk  is  the  last  chunk  of  a  multi -chunk  command. 
Hence,  the  following  sequences  of  chunks  (the  letter  corresponds  to 
the  chunk  usage  identifier  in  each  chunk,  and  the  angle  brackets 
enclose  a  chunk)  are  legal: 

<C> 

<F><L> 

<F><M><M><L> 

while  the  following  are  not  legal: 

<L> 

<M><L> 

<F><C> 

Tactics  for  handling  multiple  chunks  with  regard  to  OPE  buffering 
limits  are  left  to  the  in^nuity  of  OPE  builders.  The  spirit  is  to 
take  as  much  as  you  can,  in  order  to  relieve  the  Host  of  the 
necessity  of  buffering  Itself. 

A  command  always  begins  immediately  following  the  indicator 
character,  with  possible  intervening  spaces.  This  izq>lies  a  chunk 
can  contain  at  most  one  complete  command.  The  end  of  the  command 
(not  including  the  data)  is  signified  by  a  newline  (denoted  as  <nl> 
in  this  document)  that  does  not  appear  inside  a  quoted  string  (see 
below) .  The  end  of  the  data  is  designated  by  the  end  of  the  last 
chunk. 

Commands  take  the  form  of  an  ASCII  string.  The  command  identifier  is 
the  first  word  of  the  chunk.  It  consists  of  at  least  the  first  two 
letters  of  the  command,  in  either  imper  or  lower  case  (e.g.,  the 
sequences  "BE”,  "Be",  "bE”,  and  **be^'  all  identify  the  Begin  command)  . 
Additional  letters  of  the  command  name  can  be  included  if  desired  to 
aid  readability  of  the  command  stream. 

Following  the  command  identifier  is  a  list  of  parameters.  These 
parameters  are  also  represented  as  ASCII  strings,  although  the 
specific  format  will  depend  on  the  particular  parameter.  The  data  to 
be  transmitted  is  not  considered  a  control  parameter,  however,  and 
need  not  be  ASCII  data. 

Parameters  are  separated  by  one  or  more  spaces.  Tabs,  newlines,  and 
other  white  space  are  not  legal  parameter  separators. 

r  Parameter  strings  may  be  quoted,  using  the  character  <">.  Any 
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characters  between  the  <”>  characters  are  a  part  of  the  parameter, 
including  spaces  and  newlines.  The  character  <">  that  is  part  of  the 
parameter  is  represented  inside  a  quoted  string  as  <"'*>. 

The  order  in  which  the  parameters  appear  within  the  command  is 
significant  to  their  interpretation  by  the  Host  and  by  the  OPE. 
Optional  parameters  may  be  skijped  by  using  the  characters  " , , "  to 
indicate  a  NULL  parameter.  Such  a  NULL  parameter  takes  its  default 
value.  Alternatively,  each  parameter  has  a  MULTI CS/UNIX  style 
Control  Argument/Flag  associated  with  it  that  can  be  used  to  identify 
the  parameter,  without  placing  NULL  parameters  for  each  parameter 
skipped.  This  flag  consists  of  one  or  two  ASCII  characters,  and 
either  upper  or  lower  case  may  be  used.  For  example,  if  the  fourth 
parameter  of  a  command  had  a  flag  of  **-p'*  and  the  user  wished  the 
first  tiiree  parameters  to  be  null,  he  could  use: 

command  -p  value 

or 

command  -P  value 
instead  of 

command  , ,  , ,  , ,  value 

if  it  were  more  convenient  for  the  Host  to  do  so.  Flagged  parameters 
must  still  appear  in  the  correct  sequence  within  the  command, 
however . 

There  may  be  data  associated  with  some  of  the  commands.  Any  such 
data  is  placed  into  the  chunk  following  all  the  parameters  and  the 
unquoted  newline.  Padding  can  be  provided  by  placing  spaces  between 
the  end  of  the  final  parameter  string  and  the  newline,  so  that  data 
begins  on  a  word  boundary.  The  OPE  will  always  pad  to  a  host  word 
boundary.  Padding  by  hosts  is  optional. 

Syntax  of  Responses 

Responses  are  actually  just  a  special  form  of  a  consnand.  It  Is 
anticipated  that  all  responses  would  fit  into  i  single  channel  chunk, 
although  the  mechanisms  descrlbesd  for  multlchunk  commands  can 
certainly  be  used  in  responses.  The  ASCII  string  used  to  uniquely 
identify  the  response  command  is  ”R£'*  (‘’Re“.  ’VE".  and  ’Ve"  are  also 
permitted)  . 

After  the  resqponse  command  identifier  is  the  original  command 
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identifier,  so  the  response  can  be  associated  with  the  proper 
command.  Following  this  identifier  is  a  three  ASCII  digit  response 
code,  a  set  of  protocol  idiosyncratic  parameters,  and  a  textual 
message.  The  protocol  idiosyncratic  parameters  are  used  to  transfer 
interface  information  between  the  Host  and  the  OPE,  and  may  not  be 
needed  when  off-loading  some  protocol  interpreters .  The  textual 
message  is  intended  for  human  interpretation  of  the  response  codes, 
and  is  not  required  by  the  protocol.  The  three  digits  uniquely 
identify  the  semantics  of  the  response,  at  least  within  the  context 
of  a  particular  command  and  particular  outboarded  protocol 
interpreter . 

Responses  are  numerically  grouped  by  the  type  of  information  they 
convey.  The  first  digit  identifies  this  groip,  and  the  last  two 
digits  further  qualify  the  r^ly.  The  following  list  illustrates 
this  groiping. 

OXX  Successful:  The  command  was  executed  successfully.  The 
response  code  may  contain  further  information. 

IXX  Conditional  Success:  The  command  was  executed  successfully, 
but  not  exactly  according  to  the  service  and  flow  control 
suggestions.  If  those  suggestions  were  particularly  Important 
to  the  requester,  he  may  wish  to  issue  an  End  command.  The 
response  code  contains  information  on  what  suggestion  or 
suggestions  could  not  be  followed. 

2XX  Conmand  Level  Error:  An  error  at  the  command  level  has 
occurr€xi.  This  could  include  requesting  services  of  a 
protocol  not  supported,  or  a  problem  in  the  way  those  services 
were  requested.  This  level  does  not  Include  problems  **-ith  the 
syntax  of  the  command  or  its  parameters. 

3XX  Syntax  and  Parameter  Errors:  An  error  in  the  syntax  of  the 
connnand  or  a  problem  with  one  of  its  parameters  has  occurred. 

A  problem  with  a  parameter  may  be  other  than  syntactical,  such 
as  illegal  address. 

4XX  Off-loaded  Protocol  Interpreter  Problems:  Some  problem  with 
the  particular  off-loaded  protocol  has  occurred. 

5XX  Local  OPE  Internal  Problems:  Problems,  such  as  insufficient 
OPE  resources,  or  problems  with  OPE  to  subnet  interface. 

6XX  Security  Problem:  Some  problem  with  Host,  network,  or  CVE 
security  has  occurred.  The  response  code  indicates  thj 
problem . 
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7XX  Reserved  for  Future  Expansion 
8XX  Reserved  for  Future  Expansion 

9XX  Protocol  Idiosyncratic  Errors:  Some  error  occurred  that  is 
idiosyncratic  to  the  particular  off-loaded  protocol  being 
used.  Iho  response  code  indicates  the  error. 

Description  of  the  Commands 

As  stated  above,  communication  between  the  Host  and  the  OPE  at  the 
Command  Level  is  accomplished  using  commands  and  responses.  Commands 
may  be  issued  by  either  the  Host  or  the  OPE,  and  are  used  to 
stimulate  activity  in  the  other  entity.  Some  commands  may  only  have  a 
meaningful  Interpretation  in  one  direction,  however.  A  response 
indicates  that  the  activity  started  by  the  command  was  completed,  and 
a  code  indicates  success  or  failure  of  the  command,  and  perhaps  other 
Information  related  to  the  command  as  well. 

Associated  with  each  command  is  a  set  of  parameters.  The  order  in 
which  the  parameters  appear  is  significant  to  the  correct  operation 
of  tl^e  protocols.  More  information  on  the  syntax  of  command 
parameters  can  be  found  in  the  syntax  descriptions. 

The  commands  are: 

-  Begin:  initiate  communication  between  a  process  in  the  Host  and 
an  off-loaded  protocol  interpreter  in  the  OPE.  (A  Channel  level 
ctream/connection  will  typically  have  been  opened  as  a  prior  step. 
All  other  commands,  except  No-op,  apply  to  a  stream  on  vhich  a 
successful  Begin  has  been  done.) 

-  Transmit:  transmit  data  between  a  process  in  the  Host  and  an 

loaded  protocol  interpreter  in  the  OPE. 

-  Signal:  cause  an  out-of-band  signal  to  be  sent  by  the 
off-loaded  protocol  Interpreter  to  its  peer,  or  indicate  the 
arrival  of  such  a  signal  from  the  remote  side. 

-  Condition:  alter  the  off-loaded  protocol  interpreter's 
operational  characteristics. 

-  Status:  transfer  status  requests  or  information  between  a 
process  in  the  Host  and  an  off-loaded  protocol  interpreter  in  the 
OPE. 
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-  End:  indicate  that  services  from  the  off-loaded  protocol 
Interpreter  are  no  longer  required,  or  will  no  longer  be  provided. 

-  No-op:  performs  no  operation,  but  facilitates  testing. 

These  commands  will  be  discussed  in  the  following  sections.  Each  of 
these  sections  includes  a  discussion  of  the  purpose  of  the  command,  a 
description  of  each  of  the  parameters  used  with  the  command,  a  list 
of  responses  for  the  command,  an  example  of  the  command,  and  a  set  of 
notes  for  the  implementor.  (An  appendix  will  eventually  be  furnished 
for  each  protocol  offloading,  showing  the  use  of  its  protocol 
idiosyncratic  parameters  as  veil  as  of  the  general  parameters  on  a 
per -command  basis.  Initially,  only  representative  off  loadings  will 
be  treated  in  appendices,  with  others  to  be  added  after  the  protocol 
gains  acceptance.) 

Begin 

Purpose  of  the  Begin  Command 

The  purpose  of  a  Begin  command  is  to  initiate  communication 
between  the  Host  and  the  OPE  on  a  particular  stream  or  channel 
(the  channel  is  opened  as  a  separate  step,  of  course)  .  The 
interpretation  of  the  command  is  somewhat  dependent  \.pon 
whether  it  was  issued  by  the  Host  of  the  OPE. 

-  If  the  command  was  issued  by  the  Host,  it  means  some  process 
in  the  Host  is  requesting  services  of  a  protocol  that  was 
off-loaded  to  the  OPE.  The  user  request  results  in  the 
establishment  of  a  channel  connection  between  the  Host  and  the 
OPE,  and  a  Begin  consnand  to  the  Command  interpreter  in  the  OPE. 

-  If  the  command  was  issued  by  the  OPE,  it  means  some  protocol 
interpreter  in  the  OPE  has  data  for  some  process  in  the  Host 
which  is  not  currently  known  by  the  OPE.  An  example  would  be 
an  Incoming  UDP  datagram  on  a  new  port,  or  if  no  Begin  for  UDP 
had  been  issued  at  all  by  the  Host.  (An  incoming  TCP 
connection  request  could  be  handled  by  a  response  to  the  user’s 
Passive  Open  request,  which  had  previously  caused  a  Begin 
request  from  the  Host;  an  incoming  TCP  connection  request  to  a 
port  on  which  no  Listen  had  becm  issued  uld  cause  an  OPE 
generated  Begin,  however.) 

As  indicated  earlier,  any  particular  Host  .s  not  required  to 
support  two-way  Begins. 


Lilienkanp  6  Mandell  &  Padlipsky 


[Page  121 


MILITARY  STANDARDS:  HFE 


RFC  929  Deceinber  1984 

Proposed  Host -Front  End  Protocol 


Parameters  of  the  Begin  Command 

The  Begin  command  has  several  parameters  associated  with  it. 
These  parameters  contain  information  needed  by  the  offloaded 
protocol  to  provide  an  adequate  level  of  network  service.  This 
information  includes  protocol,  source  and  destination 
addresses,  and  also  type  of  service  and  flow  control  advice. 
These  parameters  are  discussed  in  detail  below. 

Protocol 

The  protocol  parameter  identifies  that  off-loaded  protocol  in 
the  OPE  to  which  Begin  is  directed,  or  which  issued  the  Begin 
to  the  Host.  For  exaiqple,  if  the  user  wished  to  utilize  TCP 
services,  and  the  TCP  software  was  off-loaded  into  the  OPE, 
than  the  Protocol  parameter  for  the  Begin  conanand  would  be  TCP. 

There  are  two  categories  of  protocol  parameters  --  generic  and 
specif ic.  A  generic  parameter  identifies  a  type  of  protocol 
service  required,  but  does  not  identify  the  actual  protocol. 

Use  of  generic  protocols  allows  a  Host  process  to  obtain 
network  services  without  specific  knowledge  of  what  protocol  is 
being  used;  this  could  be  appropriate  for  use  in  situations 
where  no  iqpecific  aspect (s)  of  a  iq^ecific  protocol  is/are 
required.  For  exaople,  the  user  may  select  a  generic 
Hbst-to-Kbst  connection  protocol,  and  (at  some  point  in  the 
future)  may  actually  receive  services  from  either  TCP  or  the 
KBS  Transport  Protocol,  depcMnding  on  the  network  (or  even  the 
foreign  Ifost)  in  q^iestion.  A  specific  protocol  parameter 
identifies  some  particular  protocol,  e.g.,  TCP,  whose  use  is 
required  for  the  given  channel. 

The  valid  entries  for  the  protocol  field  include: 


Generic 

%>acific 

Comment 

CIP 

IP 

Datagram  Internetwork  Protocol 

HHP 

TCP 

Connection  Transport/Host-Host  Protocol 

GDP 

UDP 

Datagram  Transport/Host-Host  Protocol 

VTP 

TEL 

Virtual  Terminal  (Telnet)  Protocol 

GFP 

FTP 

File  Transfer  Protocol 

MAIL 

SMTP 

Mail  Transfer  Protocol 

PROX 

PROX 

Prorimate  Net  Interface  Protocol 

(Note  that  the  final  line  is  meant  to  allow  for  a  process  In  an 
OPE'd  Host's  getting  at  the  PI  of  the  Network  Interface 
Protocol  for  whatever  the  proximate  network  Is.  Of  course,  so 
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doing  only  makes  sense  in  specialized  contexts.  We  conceive  of 
the  desirability  of  ”punping  bits  at  a  peripheral”  on  a  LAN, 
though,  and  don't  want  to  preclude  it,  even  if  it  would  be 
ispossible  on  many  LAN's  to  deal  with  the  problem  of 
distinguishing  traffic  coming  back  on  the  LAN  in  this  "raw" 
mode  from  normal,  IP  traffic.  Indeed,  In  some  contfwcts  it  is 
likely  that  administrative  considerations  would  preclude 
avoidance  of  IP  even  if  technical  considerations  allowed  it, 
but  it's  still  the  case  that  "the  protocol"  should  provide  a 
hook  for  going  directly  to  the  L  I  protocol  in  play.) 

There  is  no  default  value  for  this  parameter.  If  it  is  not 
prfwent,  the  Begin  commamd  is  in  error.  The  control  flag  for 
this  parameter  is  -pr. 

Active/Passive 

The  Active/Passive  parameter  indicates  %ihether  the  issuer  of 
the  l^ln  command  desires  to  be  the  Active  or  Passive  user  of 
the  protocol.  This  parameter  is  particularly  relevant  to 
connection-oriented  protocols  such  as  TCP,  where  the  user  may 
actively  pursue  connection  establishment,  or  else  may  passively 
%niit  for  the  remote  entity  to  actively  establish  the 
connection;  it  also  allows  some  process  to  establish  itself  as 
the  Host  "fielder"  of  incoming  traffic  for  a  connectionless 
protocol  such  as  IP. 

Active  is  requested  using  the  single  character  "A".  Passive  is 
Indicated  using  the  character  "P".  The  default  value  of  this 
parameter  is  "A".  Also,  when  the  C^E  issues  the  Begin  coanand, 
the  value  must  be  "A".  The  control  flag  for  this  parameter  Is 

Foreign  Address  Primary  Coqponent 

The  addressing  structure  supported  by  H-FP  is  two  level.  Each 
address  has  two  coii|3onents,  the  primary  and  the  secondary.  The 
exact  interpretation  of  these  two  components  is  protocol 
specific,  but  some  generalities  do  apply.  The  primary 
component  of  the  address  identifies  where  the  protocol  is  to 
deliver  the  information.  The  secondary  component  identifies 
which  recipient  at  that  location  is  to  receive  the  information. 
For  exaiqple,  the  TCP  primary  adc^ress  component  is  the  Host's 
Internet  Address,  while  the  secondary  address  component  is  the 
TCP  port.  Similarly.  IP's  primary  address  coaporMVit  is  the 
Host's  Internet  Address,  and  the  secondary  addresut  conponent  is 
the  IP  ULP  field.  Some  protocols  provide  only  a  i^ingle  level 
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of  addressing,  or  the  secondary  level  can  be  deduced  from  some 
other  Information  (e.g.,  Telnet).  In  these  cases,  only  the 
primary  component  is  used.  To  cater  to  such  cases,  the 
secondary  conponent  parameter  comes  later  In  the  parameter 
list. 

The  Foreign  Address  Primary  Conponent  parameter  contains  the 
primary  conponent  of  the  destination  address.  It  may  be  in 
either  a  numeric  or  symbolic  form.  (Note  that  this  allows  for 
the  OPE  to  exercise  a  Name  Server  typtj  of  protocol  if 
appropriate,  as  well  as  freeing  the  Host  from  the  necessity  of 
maintaining  an  in-board  name  to  address  table.)  The  default 
value  for  this  parameter,  although  it  only  makes  sense  for 
Passive  Begins,  is  "Any  Host".  The  control  flag  for  this 
parameter  is  -fp. 

Mediation  Level 

The  mediation  level  parameter  is  aik  Indication  of  the  role  the 
Host  wishes  the  OPE  to  play  in  the  operation  of  the  protocol. 
The  extreme  ranges  of  this  mediation  would  be  the  case  where 
the  Host  wished  to  remain  conpletely  uninvolved,  and  the  case 
where  the  Hcst  wished  to  make  every  possible  decision.  The 
specific  interpretation  of  this  parameter  is  dependent  upon  the 
particular  off-loaded  protocol. 

The  concept  of  mediation  level  can  best  be  clarified  by  means 
of  exanpXe.  A  full  inboard  ispleraentation  of  the  Telnet 
protocol  places  several  responsibilities  on  the  Host.  These 
rei^ponsibilities  include  negotiation  and  provision  of  protocol 
options,  translation  between  local  and  network  character  codes 
and  formats,  and  monitoring  the  well-known  socket  for  Incoming 
connection  requestJ^.  The  mediation  level  Indicates  whether 
these  responsibilities  are  assigned  to  the  Host  or  to  the  OPE 
\dvBn  the  Telnet  implementation  is  outboard.  If  no  OPE 
mediation  is  selected,  the  Host  is  involved  with  all 
negotiation  of  the  Telnet  options,  and  all  format  conversions. 
With  full  OPE  mediation,  all  option  negotiation  and  all  format 
conversions  are  performed  by  the  OPE.  An  intermediate  level  of 
mediation  might  have  ordinary  option  negotiation,  format 
conversion,  and  socket  monitoring  done  in  the  OPE.  while 
options  not  loiown  to  the  (^E  are  handled  by  the  Host. 

The  parameter  is  represented  with  a  single  ASCII  digit.  The 
value  9  repr€»ents  full  OPE  mediation,  and  the  value  0 
r^resents  no  OPE  mediation.  Other  values  may  be  defined  for 
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some  protocols  (e.g.^  the  intermediate  mediation  level 
discussed  above  for  Telnet)  .  The  default  value  for  this 
parameter  is  9.  The  control  flag  for  this  parameter  is  -m. 

Tra^sEmit  Response  Discipline 

The  Transmit  Response  Discipline  parameter  is  used  to  set  the 
desired  action  on  the  OPE's  part  for  generating  responses  to 
Transmit  comnands.  Essentially  the  parameter  determines  when 
the  0PE*s  response  to  the  transmit  command  occurs  (i.e.« 
ixomediately  or  delayed)  . 

The  Transmit  Re^nse  Discipline  value  is  represented  by  a 
single  ASCII  character.  The  character  '*N"  is  used  for 
nonblocking  Transmit  cozmaands.  which  implies  that  responses  for 
Transmit  commands  should  be  generated  as  soon  as  the  command 
has  befHi  examiniKi  for  correctness  (i.e.,  that  the  syntax  is 
good  and  the  parameters  appear  reasonable)  .  In  other  words, 
the  outboard  protocol  interpreter  has  the  data  in  its  qpieue, 
but  hasn't  necessarily  transmitted  it  to  the  net.  The 
character  "B"  is  used  for  blocking  Transmit  coaaands,  which 
requests  that  the  reiq>onsa  not  be  generated  until  the  protocol 
interpreter  has  successfully  transmitted  the  data  (umiless,  of 
course,  the  Transmit  command  %ms  badly  formed) .  The  default 
value  for  this  parameter  is  "N",  or  a  nonblocking  Transmit 
command.  The  control  flag  for  this  parameter  is  -tr. 

(Depending  on  the  protocol  in  play,  ^‘success fully  transmitted" 
miq^t  well  isply  that  an  acknowledgpant  of  some  sort  has  been 
received  from  the  foreign  Host,  but  for  other  protocols  it 
might  only  mean  that  the  given  collection  of  bits  has  been 
passed  from  the  OPE  to  the  proximate  net.) 

Foreign  Address  Secondary  Component 

The  addressing  mechanisms  supported  b^^  thxs  level  of  H-FP  are 
discussed  above.  The  Foreign  Address  Secondary  Component 
parameter  contains  the  value  of  the  destination  address's 
secondary  component.  Some  protocols  do  not  require  this 
parameter,  or  can  obtain  it  from  other  information.  Therefore, 
the  default  value  for  this  parameter  .*s  NULL.  A  NULL  secondary 
cooponent  might  be  an  error  for  some  protocols,  however.  The 
secondary  component  can  be  expressed  either  numerically  or 
syaibolically .  The  control  flag  for  this  parameter  Is  -fs. 

(Note  that  it  is  intended  to  be  "legal"  to  specify  a  Secondary 
Component  other  than  the  Well-Known  Socket  for  the  protocol  in 
play;  in  sxich  cases,  the  result  should  be  that  the  virtualizing 
of  the  given  protocol  be  applied  to  the  stream,  in  the 
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expectation  that  that's  vhat  the  other  side  is  expecting.  This 
is  to  cater  to,  for  example,  a  Terminal -Terminal  protc  col  that 
merely  "does  Telnet"  to  a  socket  other  than  the  usual  Logger.) 

Local  Address  Secondary  Component 

The  Local  Address  Secondary  Conponent  parameter  contains  the 
value  of  the  local  address's  secondary  component.  (The  primary 
component  is  assumed  to  be  the  default  for  the  Host,  but  can  be 
altered  as  well;  see  below.)  Some  protocols  do  not  require  this 
parameter,  or  can  obtain  it  from  other  information.  In  some 
cases,  the  OPE  nay  already  know  the  value  for  this  parameter 
and  therefore  not  require  it.  The  default  value  of  this 
parameter  is  NULL.  The  local  address  secondary  component  can 
be  esqpressed  either  numerically  or  symbolically.  The  control 
flag  for  this  parameter  is  -Is. 

Begin  Timeout  Interval 

After  a  Begin  command  is  issued,  a  timer  can  be  started.  If 
the  activity  requested  cannot  be  performed  within  some  timed 
interval,  then  the  Begin  command  may  empire.  An  esqpired  Begin 
command  returns  a  rosponse  code  indicating  a  Begin  timeout 
occurred.  The  Begin  Timeout  Interval  parameter  contains  the 
length  of  time  the  timer  will  run  before  the  Begin  timeout 
occurs. 

The  parameter  is  r^resented  as  a  string  of  ASCII  digits 
indicating  the  time  interval  in  sef:onds.  The  default  value  of 
this  parameter  is  infinity  (i.e.,  the  B«igin  command  will  never 
timeout)  .  The  control  flag  for  this  parameter  is  -bt. 

Type  of  Service  Advice 

The  Type  of  Service  Advice  parameter  contains  information  on 
the  service  characteristics  the  user  desires  from  the  offloaded 
protocol.  Included  In  this  parameter  Is  the  preccsdunce  of  the 
data  transfer,  and  also  indication  of  whether  high  throughput, 
fast  re^xMnse  time,  or  low  error  rate  Is  the  primary  goal . 

The  format  of  this  parameter  Is  a  letter  immediately  (i.e.  no 
Intervening  spaces)  followed  by  a  digit.  The  letter  ’T*' 
indicates  that  high  throughput  is  desired.  The  letter  "R" 
indicates  minimal  re^^onse  time  is  the  goal .  The  letter  "E" 
indicates  that  low  error  rates  are  the  goal.  The  letter  ‘*N" 
indicates  there  are  no  special  service  requirements  to  be 
conveyed.  The  digit  immediately  following  the  character 
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Indicates  the  desired  precedence  level «  with  zero  being  the 
lowest,  and  nine  being  the  highest.  The  specific 
interpretation  of  this  parazzMiter  is  dependent  on  what  service 
options  are  provided  by  the  protocol .  The  default  value  of 
this  parameter  is  the  lowest  precedence  (ROUTINE) ,  and  no 
i^pecial  service  requests.  The  control  flag  for  this  parameter 
is  -ts. 

Flow  Control  Advice 

The  Flow  Control  Advice  parameter  contains  information  on  the 
flow  characteristics  desired  by  the  user.  Some  applications 
such  as  file  transfer  operate  more  efficiently  if  the  data  is 
transferred  in  large  pieces,  while  other,  more  interactive 
applications  are  more  efficiently  served  if  smaller  pieces  are 
used.  This  parameter  then  indicates  whether  large  or  small 
data  blocks  should  be  used.  It  is  only  relevant  in  stream  or 
connection-oriented  protocols,  where  the  user  sends  more  than  a 
single  piece  of  data. 

This  parameter  is  represented  by  a  single  ASCII  digit.  A  value 
0  means  the  data  should  be  sent  in  relatively  small  blocks 
(e.g.,  character  or  line  oriented  applications),  while  a  val*je 
9  means  the  data  should  be  sent  in  relatively  large  blocks 
(e.g.,  block  or  file  oriented  applications).  Other  values 
represent  sizes  between  those  ejctrenes.  The  character  '*N'* 
indicates  that  no  special  flow  control  advice  is  provided.  The 
actual  interpretation  of  this  parameter  is  dependent  on  the 
particular  protocol  in  the  <^£.  The  default  value  of  this 
parameter  is  no  fl'?w  control  advice.  In  this  case,  the  protocol 
in  the  OPE  will  operate  based  only  cn  information  available  in 
the  OPE.  The  control  flag  for  this  parameter  is  -fc. 

Local  Add  iss  Primary  Conponent 

This  parameter  contains  the  local  address  primary  component.  It 
Is  anticipated  that  under  most  circumstances,  this  component  Is 
known  to  both  the  Host  and  the  OPE.  Consequently,  this 
parameter  is  seldom  reqvared.  It  would  be  useful  if  the  Host 
desired  to  select  or.e  of  several  valid  addresses,  however.  The 
control  flag  for  this  parameter  is  -Ip. 

Security 

The  security  parameters  contain  a  set  of  security  level, 
coepartment,  community  of  interest,  and  handling  restriction 
infomuitlon.  Currently,  security  is  provided  by  performing  all 
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processing  at  system  high  level  or  at  a  single  level . 
Consequently,  these  parameters  are  probably  redundant,  since 
the  security  information  is  known.  In  the  future,  however, 
these  parameters  may  be  required.  Therefore  a  field  is 
provided.  The  control  flag  for  this  parameter  is  -s. 

Pr  .tcol  Idiosyncratic  Parameters 

The  remaining  parameters  are  protocol  idiosyncratic.  That  is, 
each  protocol  that  is  off-loaded  may  have  a  set  of  these 
parameters,  which  are  documented  with  a  description  of  the 
off-loaded  protocol.  The  default  value  for  these  parameters  is 
NULL,  unless  otherwise  specified  by  a  particular  offloaded 
protocol.  The  control  flag  for  this  set  of  parameters  is  -pi, 
which  identifies  the  first  protocol  idiosyncratic  parameters. 
Control  flags  for  other  protocol  idiosyncratic  parameters  must 
be  defined  for  each  off-loaded  protocol. 

Data 

After  the  Protocol  Idiosyncratic  Parameters,  if  any,  and  the 
required  <nl>,  if  the  protocol  in  play  allows  for  it  at  this 
juncture  the  rest  of  the  chunk  will  be  interpreted  as  data  to 
be  trsmsmitted.  That  is,  in  connection  oriented  protocols  data 
may  or  may  not  be  permitted  at  connection  initiation  time,  but 
in  connectionless  protocols  it  certainly  makes  sense  to  allow 
the  H-FP  Begin  command  to  convey  data.  (This  will  also  be 
useful  when  we  get  to  the  Condition  command.) 

Responses 

The  following  responses  have  been  identified  for  the  Begin 
command : 

000  Command  coicpleted  successfully 

101  Througtput  not  available;  using  maximum 

102  Reliability  not  available;  using  maximum 

103  Delay  not  available;  using  minimum 

110  Flow  Control  advice  not  followed;  smaller  blocks  used 

111  Flow  Control  advice  not  followed;  larger  blocks  used 

201  Failed;  Begin  not  inplemented  in  this  direction 

202  Failed;  timeout 

203  Failed;  Begin  command  on  already  active  channel 

300  Problem  with  multiple  chunks 

301  Syntax  problem  with  Begin  command 

302  Protocol  not  sugf^orted  in  OPE, /Host 

303  Active  service  not  available 
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304  Passive  service  not  available 

305  Invalid  Foreign  Address  Primary  Conroonent 

306  Invalid  Transmit  Discipline 

307  Invalid  Foreign  Address  Secondary  Component 

308  Invalid  Local  Address  Secondary  Conponent 

309  Invalid  Timeout  Interval 

310  Invalid  Type  of  Service  Advice 

311  Invalid  Flow  control  Advice 

312  Invalid  Local  Address  Primary  Component 

401  Protocol  Interpreter  in  OPE  not  responding 

402  Remote  Protocol  Interpreter  not  available 

403  Failed;  insufficient  protocol  interpreter  resources 

501  Failed;  insufficient  OPE  resources 

601  Request  violates  security  policy 

602  Security  parameter  problem 

Additionally,  protocol  Idiosyncratic  responses  will  be  defined 
for  each  off-loaded  protocol. 

Example  of  Begin  Command 

The  Begin  coraomand  is  the  most  complex  of  the  H-FP  Command 
Level.  When  the  off-loaded  protocol  is  TCP,  the  Begin  command 
is  used  to  open  TCP  connections.  One  possible  example  of  a 
Begin  command  issued  by  an  inboard  Telnet  interpreter  to  open  a 
TCP  connection  to  ISIA,  with  no  begin  timeout  interval,  is: 


C  BE  TCP  A  ISIA  9  N  23 


NO  S  <nl> 


Where: 

TCP 

A 

ISIA 

9 

N 

23 


Ihe  code  for  the  protocol  TCP 
Indicates  Active  ^gin 
The  name  of  a  Host  at  USC-ISI 
Mediation  Level  9:  Full  OPE  mediation 
Non-blocking  transmit 
Destination  Telnet  Port 

skip  over  parameters  (Local  Address  Secondary, 
Begi.a  Timeout  Interval) 

Ty^  of  Service  Advice:  No  special  Advice, 
Normal  Precedence 

Flow  Control  Advice:  use  small  blocks 


This  command  will  cause  the  OPE  to  invoke  the  TCP  interpreter 
to  generate  the  Initial  SYN  packet  to  the  well-known  Telnet 
socket  on  Host  ISIA.  It  also  informs  the  OPE  to  do  all  TCP 
related  processing  via  the  Mediation  Level,  accepts  default 
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Local  Address  parameters,  and  sets  the  Begin  Timeout  Interval 
to  infinity.  The  precedence  of  the  TCP  connection  is  Normal, 
and  the  TCP  interpreter  is  informed  that  the  data  stre£mi  will 
consist  of  primarily  small  blocks. 

Notes  to  the  Implementor 

Response  203  might  seem  silly  to  some  readers,  but  it’s  there 
in  case  somebody  goofed  in  using  the  Channel  Layer. 

Transmit 

Purpose  of  the  Transmit  Command 

The  purpose  of  the  Transmit  command  is  to  permit  the  process  in 
the  Host  to  send  data  using  an  off-loaded  protocol  interpreter 
in  the  OPE,  and  also  to  permit  the  OPE  to  deliver  data  received 
from  the  network  destined  for  the  process  in  the  Host.  The 
Transmit  command  is  particularly  relevant  to  connection  and 
stream  type  protocols,  although  it  has  applications  for 
connectionless  protocols  as  well.  After  the  Begin  coimnand  is 
issued  successfully  and  the  proper  Response  received.  Transmit 
commands  can  be  issued  on  the  given  channel.  1^16  semantics  of 
the  Transmit  command  depend  on  whether  it  was  issued  by  the 
Host  or  the  OPE. 

-  If  the  Host  issues  the  Transmit  command,  a  process  in  the 
Host  wishes  to  send  the  data  to  the  destination  specified  to 
the  off-loaded  protocol  Interpreter  that  was  established 
(typically)  by  a  previous  Begin  command  on  the  given  H-FP 
channel . 

-  If  the  OPE  issues  the  command,  the  OPE  has  received  data 
destined  for  a  process  in  the  Host  from  a  connection  or  stream 
supported  by  the  off-loaded  protocol  that  was  established  by  a 
previous  Begin  command  on  the  given  H-FP  channel . 

Parameters  of  the  Transmit  Command 

The  Transmit  command  has  one  parameter  associated  with  it.  It 
is  an  optional  parameter,  to  temporarily  o  wride  the  response 
discipline  for  this  particular  transmit  command.  Some  protocols 
may  have  protocol -idiosyncratic  parameters  as  well.  The 
transmit  command  also  has  data  associated  with  it.  All 
parameters  must  precede  the  data  to  be  transmitted. 
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Response  Discipline  Override 

The  Response  Discipline  Override  parameter  Indicates  the 
desired  response  discipline  for  that  individual  Transmit 
Command,  overriding  the  default  response  discipline.  A  single 
ASCII  character  is  used  to  indicate  the  desired  discipline. 

The  character  "N"  indicates  that  this  Transmit  command  should 
not  block,  and  should  return  a  response  as  soon  as  the  data  is 
given  to  the  protocol  interpreter  in  the  OPE.  The  character  "B" 
indicates  that  this  Transmit  command  should  block,  meaning  that 
a  response  should  not  be  generated  until  the  data  has  been  sent 
to  the  destination.  The  default  value  of  this  parameter  is  the 
currently  defined  Transmit  Command  response  discipline.  The 
use  of  this  parameter  does  not  alter  the  currently  defined 
Transmit  command  response  discipline;  the  default  is  changed 
with  the  Condition  command.  The  control  flag  for  this 
parameter  is  -rd. 

Protocol -Idiosyncratic  Parameters 

Any  other  parameters  to  the  Transmit  command  are 
protocol -idiosyncratic.  That  is,  each  protocol  that  is 
off-loaded  has  a  set  of  these  parameters,  which  are  documented 
vlth  a  description  of  the  off-loaded  protocol.  The  default 
value  for  these  parameters  is  NULL,  unless  otherwise  specified 
by  a  particular  off-loaded  protocol.  The  control  flag  for  this 
set  of  parameters  is  -pi,  which  Identifies  the  first 
protocol -idiosyncratic  parameters.  Control  flags  for  other 
protocol -idiosyncratic  parameters  must  bo  defined  for  each 
off-loaded  protocol. 

Responses 

The  following  responses  for  the  Transmit  command  have  been 
identified: 

000  Transmit  Command  completed  successfully 

201  Transmit  Command  not  appropriate 

300  Problem  with  multiple  chunks 

301  Syntax  problem  with  Transmit  Command 

302  Invalid  Transmit  Command  Response  Discipline 

401  Protocol  Interpreter  in  OPE  not  responding 

402  Failure  in  remote  protocol  interpreter 

403  Failed;  insufficient  protocol  Interpreter  resources 

^Oi  Failed*  Insufficient  OPE  resources 

601  Requesr  violates  security  policy 
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Additionally,  protocol -idiosyncratic  responses  will  be  defined 
for  each  off-loaded  protocol. 

Example  of  Transmit  Command 

Tbe  transmit  command  is  used  in  TCP  to  provide  the  TCP  write 
call.  An  example  of  such  a  transmit  command  would  be: 

C  TR  N  <nl>  <DATA> 

Where  N  indicates  non-blocking  transmission  discipline,  <nl>  is 
the  required  command- ending  newline,  and  <DATA>  is  presumed  to 
be  the  user's  data  that  is  to  be  transmitted. 

Notes  to  the  Implementor 

If  you  get  a  403  or  a  501  response  and  have  sent  a  multiple 
chunk  it  probably  makes  sense  to  try  a  single  chunk;  if  you've 
sent  a  single  chunk,  it  makes  sense  to  wait  a  while  and  try 
again  a  few  times  before  giving  up  on  the  stream/channel . 

Condition 

Purpose  of  the  Condition  Command 

The  primary  purpose  of  the  Condition  command  is  to  permit  a 
process  to  alter  the  characteristics  that  were  originally  set 
up  with  the  Begin  command.  (That  is,  "condition"  is  a  verb.) 
These  characteristics  include  the  addresses,  the  mediation 
level,  the  type  of  service,  and  the  flow  control  parameters 
from  Begin.  They  may  also  include  protocol -idiosyncratic 
characteristics.  (Although  Condition  is  usually  thought  of  as  a 
Host->0PE  command,  it  may  also  be  used  OPE->Host  in  some 
contexts . ) 

Condition  is  a  generic  command  that  may  find  little  use  in  some 
off-loaded  protocols.  In  others,  only  some  of  the  parameters 
identified  may  make  sense.  For  exanple,  changing  the 
destination  address  of  a  TCP  connection  involves  closing  one 
connection  and  opening  another.  Consequently,  in  may  make  more 
sense  to  first  issue  an  End  command,  and  then  a  Begin  with  the 
new  address.  In  other  protocols,  such  as  IP  or  UDP,  changing 
the  address  on  each  datagram  would  be  a  perfectly  reasonable 
thing  to  do. 
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Parameters  of  the  Condition  Command 

The  Condition  command  has  the  same  parameters  as  the  Begin 
command.  Any  parameters  ejqpressed  in  a  Condition  command 
indicate  the  new  values  of  the  characteristics  to  be  altered; 
all  parameters  not  expressed  retain  the  current  value. 

Althou^  it  is  possible  to  express  the  change  of  any  of  the 
characteristics  originally  set  up  in  the  Begin  command  using 
the  Condition  commajid,  there  are  some  characteristics  that  do 
not  make  sense  to  alter,  at  least  for  some  protocols.  For 
example,  once  a  connection  is  opened,  it  does  not  make  much 
sense  to  change  the  Foreign  Address  Primary  or  Secondary 
Components.  Doing  so  is  inconsistent  with  current  versions  of 
TCP,  and  would  require  the  closing  of  the  existing  connection 
and  opening  a  new  one  to  another  address.  Earlier  versions  of 
TCP  did  permit  connections  to  be  moved.  If  a  protocol  that 
provided  such  a  feature  was  implemented  in  the  OPE,  the 
changing  the  Secondary  Address  Components  would  be  a  reasonable 
thing  to  do. 

Responses 

The  responses  to  the  Condition  command  are  the  same  as  those  to 
the  Begin  command. 

Example  of  Condition  Command 

The  Condition  Command  can  be  quite  complex,  and  can  be  used  for 
many  purposes.  One  conceived  use  of  the  condition  command 
would  be  to  change  the  type  of  service  advice  associated  with 
the  channel.  An  exanpl<?  of  this  (which  also  demonstrates  the 
ability  to  skip  parameters)  is: 

C  -ts  T  <nl> 

which  causes  the  offloaded  PI  associated  with  the  current 
channel  to  attempt  to  achieve  high  thr output  (in  its  use  of 
the  comm  subnet  (s)  in  play)  . 

Notes  to  the  Implementor 
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Signal 

Purpose  of  Signal  Connnand 

The  purpose  of  the  Signal  Command  (Implicitly  at  least)  is  to 
permit  the  transfer  of  out-of-band  signals  or  information 
between  the  Host  and  the*  OPE,  in  order  to  utilize  (explicitly) 
out-of-band  signaling  services  of  the  off-loaded  protocol.  The 
semantics  of  the  Signal  command  depend  upon  whether  it  was 
issued  by  the  Host  or  the  OPE. 

-  If  the  Signal  command  was  issued  by  the  Host,  it  means  a 
process  in  the  Host  desires  to  send  out-of-band  data  or  an 
out-of-band  signal. 

-  If  the  Signal  command  was  issued  by  the  OPE,  it  means 
out-of-band  data  or  an  out-of-band  signal  arrived  for  the 
process  associated  with  the  channel  in  the  Host. 

Parameters  of  the  Signal  Command 

The  basic  usage  of  the  Signal  command  is  with  no  parameters, 
which  s€Bnds  or  reports  the  receipt  of  an  out-of-band  signal. 
Some  protocols,  such  as  the  MBS  Transport  Protocol,  permit  the 
user  to  send  data  with  the  out-of-band  signal.  Hence,  data  is 
permitted  to  accompany  the  Signal  command.  There  may  also  be 
protocol -idiosyncratic  parameters  for  the  Signal  command.  If 
this  is  the  case,  these  parameters  would  come  before  the  data. 

Protocol -Idiosyncratic  Parameters 

The  parameters  for  the  Signal  command  are  protocol 
idiosyncratic.  That  is,  each  protocol  off-loaded  has  a  set  of 
these  parameters.  The  default  value  for  these  parameters  is 
their  previous  values.  Control  flags  for  multiple 
protocol -idiosyncratic  parameters  must  be  defined  for  each 
off-loaded  protocol. 

Respon.5es 

The  following  responses  have  been  identified  for  the  Signal 
command : 

000  Command  completed  successfully 

201  Command  not  appropriate 

300  Problem  with  multiple  chunks 

301  Syntax  problem  with  Command 
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401  Protocol  Interpreter  in  OPE  not  responding 

402  Failure  in  remote  protocol  interpreter 

403  Failed;  insufficient  protocol  interpreter  resources 

501  Failed;  insufficient  OPE  resources 

601  Request  violates  security  policy 

Additionally,  protocol -idiosyncratic  responses  will  be  defined 
for  each  off-loaded  protocol. 

Example  of  Signal  Command 

The  major  perceived  use  for  the  Signal  command  when  offloading 
a  connection  protocol  is  sending  an  out-of-band  signal  with  no 
data.  In  such  a  case,  the  appropriate  signal  command  would  be: 

C  SI  <nl> 

Notes  to  the  IXEplementor 

Some  protocols  may  allow  only  only  one  outstanding  signal  at  a 
time.  For  these  protocols,  it  is  an  ioplementation  issue 
\^ther  the  OPE  will  buffer  several  signals,  but  a  good  case 
could  be  made  for  the  position  that  a  scrv^ulous  OPE  would 
reflect  a  202  response  back  to  the  Host  in  such  cases. 

There  is  some  question  as  to  the  proper  handling  of  the 
''expedited  data"  notion  of  some  (particularly  ISO)  protocols. 
It  mi^t  be  more  appropriate  to  deal  with  such  a  thing  as  a 
protocol  idiosyncratic  parameter  on  the  Transmit  command 
instead  of  using  the  Signal  command  (even  if  it's  the  closest 
approximation  to  an  out-of-band  signal  in  the  given  protocol)  . 
If  it's  provided  using  the  Signal  command,  the  expedited  data 
should  not  be  passed  as  ASCII,  and  should  appear  after  the 
command- terminating  newline  character  (and  appropriate  padding 
with  space  characters) . 


Status 

Purpose  of  Status  Command 

The  purpose  of  the  Status  command  is  to  permit  the  Host  to 
request  and  obtain  status  information  from  the  OPE,  and  vice 
versa.  This  includes  status  request  of  a  conventional  protocol 
interface  (e.g,,  in  TCP,  there  is  a  request  to  determine  the 
state  of  a  particular  connection) . 
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Parameters  of  the  Status  Command 

Ihe  parameters  for  the  Status  command  indicate  \^ether  it  is  a 
request  or  a  response,  and  contain  the  status  information. 

Request/Report 

This  parameter  indicates  whether  the  command  is  a  Status 
request  or  a  Status  report.  It  consists  of  a  single  ASCII 
character .  Q  indicates  a  request  (query) ,  and  R  indicates  a 
report.  It  should  bo  noted  that  a  report  may  be  generated 
as  the  result  of  a  query,  or  may  be  generated  as  the  result 
of  specific  protocol  mechanisms. 

Protocol -Idiosyncratic  Parametcirs 

The  parameters  to  the  status  command  are 

protocol -idiosyncratic.  That  is,  each  protocol  off-loaded  has  a 
set  of  these  parameters.  The  default  value  for  these 
parameters  is  their  previous  values.  Among  these  parameters  is 
an  identifier  of  the  type  of  status  information  contained  or 
requested,  and  a  value  or  set  of  values  that  contain  the 
particular  status  information.  The  status  information  itself 
should  be  the  last  item  in  the  command.  The  control  flag  for 
this  set  of  parameters  is  -pi,  which  identifies  the  first 
protocol -idiosyncratic  parameters.  Control  flags  for  other 
protocol -idiosyncratic  parameters  must  be  defined  for  each 
off-loaded  protocol. 

Responses 

The  following  responses  have  been  identified  for  the  Status 
consoand: 

000  Command  completed  successfully 

201  Command  not  appropriate 

300  Problem  with  multiple  chunks 

301  Syntax  problem  with  Command 

302  Inappr<^riate  status  request 

303  Inappr<i)riace  status  res^nse 

401  Protocol  Interpreter  in  OPE  not  responding 

402  Failure  in  remote  protocol  interpreter 

403  Failed;  insufficient  protocol  interpreter  resources 

501  Failed;  insufficient  OPE  resources 

601  Request  violates  security  policy 

9xx  Protocol  Idiosyncratic  status  responses 
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Example  of  Status  Coi&Aand 

The  status  command  can  be  particularly  complex,  depending  on 
the  protocol  and  particular  type  of  status  information.  One 
possible  use  of  the  status  ommand  when  off-loading  TCP  is  to 
consunicate  the  status  service  request.  For  performing  this 
operation  the  status  command  would  be: 

C  ST  Q  <nl> 

Notes  to  the  Implementor 
End 

Purpose  of  the  End  Connand 

The  purpose  of  the  End  command  is  to  communicate  that  services 
of  the  off-loaded  protocol  are  not  required.  The  semantics  of 
the  End  conmand  depends  upon  whether  it  was  issued  by  the  Host 
or  the  CPE. 

-  If  the  Host  isstuM  the  End  coanand,  it  means  the  process  in 
the  Host  no  longer  requires  the  services  of  the  offloaded 
protocol . 

-  If  the  OPE  issues  the  End  connand,  it  means  the  remote  entity 
has  no  more  data  to  send  (e.g.,  the  off-loaded  protocol  is  TCP 
and  the  remote  user  has  issued  a  TCP  close)  . 

Parameters  of  the  End  Command 

One  parameter  is  associated  with  the  End  Command.  It  indicates 
whether  the  termination  should  be  "graceful"  or  "abrupt"  (see 
below)  . 

Grace  ful /Abrupt 

The  Grace  Tul/Abrupt  parameter  indicates  whether  the  End 
should  be  handled  gracefully  or  abruptly.  If  it  is  handled 
gracefully,  then  data  in  transit  is  allowed  to  reach  its 
destiriatiM-i  before  service  is  actually  terminated.  An 
abrupt  End  occurs  immediately;  all  data  transmitted  from  the 
Host  but  still  pending  in  the  OPE  is  discard^  and  no  new 
ir«coming  data  is  9V\t  to  the  Host  from  the  OE?. 
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The  parameter  Is  indicated  by  a  single  ASCII  character.  The 
character  "G"  denotes  graceful,  and  **A''  denotes  abrupt.  The 
default  value  for  this  parameter  is  graceful. 

Responses 

The  following  responses  have  been  identified  for  the  End 
command: 

000  Command  completed  successfully 

201  Connand  not  appropriate 

300  Problem  with  multiple  chunks 

301  Syntax  problem  with  Command 

302  Illegal  Type  of  End  Command 

401  Protocol  Interpreter  in  OPE  not  responding 

402  Failure  in  remote  protocol  Interpreter 

403  Failed;  insufficient  protocol  interpreter  resources 

501  Failed;  insufficient  OPE  resources 

601  Request  violates  security  policy 

Additionally,  protocol  idiosyncratic  responses  will  bo  defined 
for  each  off-loaded  protocol. 

Example  of  End  Command 

The  syntax  of  the  End  command  is  relatively  straightforward.  It 
consists  of  a  chunk  that  contains  only  a  chunk  usage 
identifier,  the  end  command  string,  and  the  parameter 
indicating  whether  the  erd  should  be  graceful  or  abnpt.  A 
possible  valid  (abrupt)  End  command  would  be: 

C  EN  A  <nl> 

Notes  to  the  Implementor 

Once  an  End  has  been  issued  in  a  given  direction  any  other 
conmands  on  the  channel  in  the  same  direction  are  in  error  and 
should  be  responded  to  appropriately. 
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No-op 

Purpose  of  the  No-op  Command 

The  No-op  command  performs  no  operation.  Its  purpose  is  to 
permit  the  Host  and  OPE  to  participate  in  a  dialog  which  does 
not  alter  the  state  of  communication  activities,  both  for 
debugging  purposes  and  to  support  features  of  certain  protocols 
(e.g.,  Telnet's  Are  You  There  conmiand)  . 

Parameters  of  the  No-op  Comnand 

There  are  no  parameters  associated  with  the  No-op  command. 

Responses 

There  are  only  two  possible  legal  responses  to  the  No-op 
comnand.  They  are: 

000  No-op  Command  Completed  Correctly 

300  Problem  with  multiple  chunks 

Example  of  No-op  Comnand 

Syntactically  the  No-op  command  is  quite  simple.  It  consists 
of  a  chunk  that  contains  only  the  chunk  usage  identifier  and 
the  string  for  the  comnand,  and  the  newline.  One  possible 
valid  No-cp  comnand  is: 

C  NO  <nl> 

Notes  to  the  Implementor 

No-ops  are  included  for  use  in  testing  and  initial 
synchronization.  (The  latter  use  is  riot  mandatory,  however. 
That  is,  no  exchange  of  No-ops  is  required  at  start-up  time, 
but  it  is  conceivable  that  some  implementatior^s  might  want  to 
do  it  just  for  exercise.)  They  are  ala^o  traditional. 
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APPENDIX 

Per-Protocol  Offloading  Descriptions 

1.  Command  Level  Interface  to  an  Off-loaded  TCP 

Ibis  appendix  discusses  the  use  of  the  commands  described  in  the 
body  of  this  document  to  provide  an  interface  between  a  Host 
process  and  an  off-loaded  interpreter  of  the  DoD's  Transmission 
Control  Protocol  (TCP) .  The  interface  described  here  is 
functionally  equiv^ent  to  the  interface  found  in  the  MIL-SID  1778 
specification  of  TCP.  It  is  not,  however,  identical,  in  that  some 
features  of  the  interface  are  particularly  relevant  only  in  an 
inboard  implementation. 

The  first  section  describes  the  mapping  between  the  interface 
events  of  MIL-STD  1778  and  the  conmands  and  responses  of  this 
H-FP,  and  hi^lhlights  the  unique  features  of  the  interface.  The 
next  sections  discuss  the  details  of  each  command.  These  details 
include  the  specialized  usages  of  the  command  and  the 
protocol -idiosyncratic  parameters  for  that  command. 

1.1.  Relation  to  MIL-STD  1778  Interface 

Most  of  the  requests  and  responses  of  the  TCP  interface 
specified  in  MIL-STD  1778  are  mapped  directly  to  H-FP  Commands 
and  responses.  The  exceptions  are  noted  in  the  following 
descriptions . 

1.1.1.  Requests 

Unspecified  Passive  Open,  Fully  Specified  Passive  Open, 
Active  Open,  and  Active  Open  with  Data  requests  are  all 
implemented  using  variations  of  the  Begin  command.  The 
distinction  between  Passive  and  Active  Open  is  made  using 
the  Active/Passive  parameter  of  Begin.  The  distinction 
between  unspecified  and  fully  specified  lies  in  the  presence 
or  absence  of  the  destination  address  fields.  An  active 
open  with  data  Is  identical  to  a  normal  active  open,  except 
for  the  presence  of  data  following  the  command. 

The  Send  Service  Request  is  isplmented  using  the  Transmit 
command.  Special  protocol  idiosyncratic  parameters  are 
provided  for  Urgent.  Push,  and  changing  the  ULP  timeout 
action  and  values.  The  response  to  the  Transmit  command 
indicates  that  the  appropriate  Send  call  has  been  made. 
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There  is  no  corresponding  response  in  the  specified  TCP 
interface;  its  only  significance  is  that  the  Host  can  issue 
another  Transmit  command. 

The  Allocate  event  is  a  specification  feature  of  MIL-STD 
1778  to  indicate  the  willingness  of  the  user  to  accept 
incoming  data  across  tlie  interface.  However,  because  this 
is  precisely  the  type  of  flow  control  provided  by  the 
Channel  level,  the  Allocate  event  would  be  a  superfluous 
mechanism.  Thus,  there  is  no  direct  analogy  to  that  event 
in  the  H-FP  interface.  A  Host  process  indicates  its 
willingness  to  accept  new  data  by  informing  the  channel  via 
its  flow  control  interface  (if  it  has  an  explicit  one) . 

Close  and  Abort  are  provided  by  the  End  command.  Close  uses 
the  graceful  version  of  the  End  command,  while  Abort  uses 
the  abrupt  version.  The  response  indicates  that  the  End 
command  has  been  rece-Wed  and  the  corresponding  Close  or 
Abort  was  issued.  There  is  no  corresponding  response  in  the 
specified  TCP  interface. 

Status  is  provided  by  using  the  query  form  of  the  Status 
command.  The  response  to  the  Status  command  contains  the 
information  (see  below) . 

1.1.2.  Responses 

The  Open  Id  response  is  provided  so  that  the  user  has  a 
shorthand  name  by  which  tc  refer  to  the  connection.  With  an 
outboarded  TCP  interpreter,  there  is  a  one-to-one  mapping 
between  TCP  connections  and  H-FP  channels.  Hence,  the  Open 
Id  event  is  not  needed,  since  the  channel  ID  is  sufficient 
to  indicate  the  desired  connection. 

Tho  Open  Failure  and  Open  Success  responses  are  provided 
using  OPE-generated  responses  to  Begin  commands  (which 
provide  the  Active  and  Passive  Service  response  primitives) 
issued  by  the  H^st.  The  value  of  tlie  response  code 
indicates  whetjier  the  Begin  command  succeeded  or  failed,  and 
can  be  mapped  to  the  appropriate  Open  Failure  or  Open 
Success  indication  by  the  Host. 

Deliver  is  provided  by  having  the  OPE  issue  a  Trarsmit 
command.  As  mentioned  above,  the  "flow  control"  between  the 
TCP  interpreter  and  the  Host  is  provided  by  the  Channel 
layer,  so  no  explicit  interface  events  are  needed.  The 
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response  to  the  Transmit  command  indicates  the  data  was 
received  by  the  Host  process.  There  is  no  corresponding 
response  in  the  specified  TCP  interface. 

The  Closing  and  Terminate  service  responses  are  provided 
using  the  End  command.  Closing  is  indicated  using  the 
graceful  version  of  the  command,  while  terminate  is  provided 
using  the  abrupt  version.  The  response  indicates  the  End 
command  was  received  by  the  Host  process.  There  is  no 
corresponding  response  in  the  specified  TCP  interface. 

Status  Response  is  provided  by  a  response  to  the  query 
version  of  the  Status  command.  The  status  information  is 
communicated  via  protocol -idiosyncratic  parameters  following 
the  Response  code. 

Error  messages  are  reported  using  the  spontaneously 
generated  version  of  the  Status  consnand  issued  by  the  OPE. 
The  error  message  is  provided  in  a  parameter.  The  response 
indicates  the  error  message  was  received  by  the  Host 
process.  There  is  no  corresponding  event  in  the  specified 
TCP  interface. 

1.2.  The  Begin  Command 

The  Begin  command  is  used  in  TCP  in  three  major  ways: 

1.  To  inform  the  OPE  that  a  process  in  the  Host  wishes  to 
open  a  connection  to  a  particular  port  on  a  internet 
address . 

2.  To  inform  the  OPE  that  a  process  in  the  Host  wishes  to  be 
informed  when  a  connection  atten^t  is  made  to  any  or  to  a 
specific  port  at  this  Host's  internet  address. 

3.  To  inform  the  Host  that  a  connection  atteiqjt  to  the  OPE 
has  arrived,  and  there  was  no  Begin  of  the  second  type 
(passive  open)  issued  by  the  Host  relevant  to  that 
particular  port. 

1.2.1.  Specialized  Usr^ ^e 

There  are  four  major  aspects  to  the  specialized  usage  of  the 
Begin  command  and  its  parameters.  These  parameters  are: 

1.  The  meaning  of  the  Mediation  Level  parameter 
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2.  The  selection  of  blocking  treatment  of  Transmit 
command 

3.  The  meaning  of  the  address  conponents 

4.  The  selection  of  the  TCP  Active  Open  with  Data 
primitive. 

The  Mediation  Level  parameter  has  only  two  possible  values 
when  offloading  TCP.  These  are  ”9"  and  "0".  The  normal 
usage  of  an  off-loaded  TCP  uses  the  value  "9”,  which  means 
the  Host  is  in  no  way  involved  in  the  operation  of  TCP.  The 
value  ”0"  indicates  the  Host  wishes  to  negotiate  with  the 
TCP  options. 

The  normal  TCP  Send  event  is  non -blocking.  That  is,  when  a 
user  issues  the  send  command,  it  counts  on  the  reliability 
services  of  TCP,  and  is  not  explicitly  notified  when  the 
data  has  reached  the  other  end  of  the  connection  and  been 
properly  acknowledged.  Hence,  the  default  value  for  this 
parameter  with  TCP  is  "N'*.  There  are  some  applications 
where  the  user  may  not  wish  to  receive  a  response  to  a 
Transmit  command  until  the  data  has  been  acknowledged  by  the 
other  end  of  the  connection.  In  these  cases,  the  value 
should  be  used  for  this  parameter.  If  such  a  feature  is  not 
supported  by  the  offloaded  TCP  interpreter,  then  it  is 
acceptable  to  issue  a  100  level  Conditional  acceptance 
indicating  that  blocking  is  not  supported,  but  the  Begin 
command  will  proceed  using  non-blocking  Transmits, 

The  primary  address  components  of  the  local  and  remote 
addresses  refer  to  the  internet  addresses  of  (or  a  symbolic 
Host  name  for)  the  respective  Hosts.  The  secondary 
conponents  refer  to  the  particular  sockets  at  those  internet 
addresses.  Normally,  the  secondary  conponents  (ports)  are 
specified  numerically.  They”  may,  however,  be  specified  by 
name  if  the  port  Is  a  well-known  service  port.  In  an  Active 
Begin  command,  the  remote  addresses  primary  and  secondary 
components  must  be  specified.  The  local  address  conponents 
need  not  be  specified,  unless  the  user  wishes  to  indicate 
that  the  connection  should  be  from  a  particular  port  or  a 
particular  internet  address  of  a  multi -homed  Host.  In  a 
Passive  Begin  command,  the  remote  addresses  are  specified 
only  if  connection  attenpts  from  one  particular  Host  are  of 
interest.  The  local  address  secondary  component  must  be 
used  to  indicate  on  which  port  to  perform  the  Listen. 
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The  way  the  TCP  Active  Open  with  data  is  provided  is  by 
including  the  data  with  the  Begin  Command.  This  data  is 
included  in  the  same  Channel  level  chunk,  immediately 
following  the  newline.  If  the  data  is  more  than  a  single 
chunk  can  hold,  chen  the  multi -chunk  command  feature  of  the 
H-FP  must  be  used. 

1.2.2.  Protocol -Idiosyncratic  Parameters 

Ihe  protocol -idiosyncratic  parameter  identified  for  the  TCP 
interface  is  the  ”ULP  timeout"  information.  This 
information  includes  whether  the  offloaded  interpreter 
should  abort  the  connection  on  a  ULP  timeout  or  report  it  to 
the  inboard  user,  and  also  the  numerical  value  of  the 
timeout  interval.  The  format  chosen  for  this  parameter  is  a 
single  letter  followed  immediately  (with  no  spaces)  by  an 
ASCII  number.  The  letter  can  be  either  "R"  or  "A",  and 
indicates  that  the  ULP  timeout  should  cause  a  rqport  or  an 
abort,  respectively.  The  number  is  interpreted  to  be  the 
timeout  interval  in  seconds. 

1.2.3.  Examples  of  the  Command 

An  example  of  an  Active  Begin  command  that  might  be  issued 
by  an  inboard  user  Telnet  is: 

C  BE  TCP  A  ISIA  9  N  23  , ,  60  R  0  -pi  R120  <nl> 

ISIA  is  the  destination  Host,  23  is  the  well-known  port 
number  for  Telnet  connections,  a  Eegin  timeout  of  60  seconds 
was  chosen.  The  desired  type  of  service  is  to  strive*  for 
good  response  time,  the  transmissions  are  expected  to  be  in 
small  units,  and  protocol -idiosyncratic  parameter  R12G 
inplies  that  a  Uli’  timeout  of  120  seconds  should  be 
reported . 

An  example  of  a  Passive  Begin  Command  that  might  be  issued 
by  an  inboard  server  Telnet  is: 

C  BE  TCP  P  , ,  9  N  , ,  23  , ,  R  0  -pi  R120  <nl> 

The  major  differences  are  that  no  remote  address  conponents 
are  specified,  and  the  local  secondary  address  component  is 
identified  as  the  socket  on  which  the  Listen  is  being 
performed.  Also,  the  default  ("infinite")  timeout  is  taken. 
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1.3.  The  Transmit  Command 

The  Transmit  command  is  used  by  the  Host  process  to  instruct 
the  off-loaded  TCP  interpreter  to  send  data  to  a  remote  site 
via  the  TCP  connection  associated  with  the  command’s  channel. 

It  is  used  by  the  OPE  to  deliver  incoming  data  from  the 
connection  to  the  process  in  the  Host. 

1.3.1.  Specialized  Usage 

The  Transmit  command  must  be  capable  of  providing  all  the 
specialized  features  of  the  Send  and  Deliver  Event.  These 
special  features  are  Urgent,  Push,  and  modification  of  the 
ULP  Timeout  action  and/or  inter'/al . 

Urgent  is  a  means  to  communicate  that  some  point  upcoming  in 
the  data  stream  has  been  marked  as  URGENT  by  the  sender. 
While  the  actual  Urgent  bit  travels  throu^  the  connection 
out-of-band,  it  carries  a  pointer  that  is  related  to  the 
sequence  numbers  of  the  in-band  communication.  Hence,  the 
urgency  must  be  indicated  in  the  Transmit  command  rather 
than  the  Signal  command. 

Push  is  a  feature  of  the  TCP  Send  Event  that  is  used  to 
indicate  that  the  data  in  the  Transmit  command  should  be 
sent  immediately  (within  the  flow  control  constraints) , 
rather  than  waiting  for  additional  send  commands  or  a 
timeout.  Push  is  indicated  in  the  Transmit  Command.  The 
push  feature  has  the  same  meaning  when  sent  from  the  OPE  to 
the  Host.  If  the  Host  inp lamentation  does  no  internal 
queuing,  the  flag  has  no  meaning. 

The  TCP  Send  evt':.nt  permits  the  user  to  modi  fy  the  "ULP 
timeout  action"  and/or  the  "ULP  timeout  interval"  associated 
with  that  connection.  When  changed,  the  new  values  take 
effect  for  the  remainder  of  the  connection,  unless  changed 
later  with  ariother  Send.  'Ihis  feature  is  provided  in  this 
H-FP  using  the  Transmit  Command. 

1.3.2.  Protocol -Idiosyncratic  Parameters 

The  three  features  identified  above  are  provided  using 
protocol - idiosyncratic  parameters . 

The  first  such  parametei  is  the  Urgent  parameter.  From  the 
point  of  view  of  the  interface,  it  is  just  a  flag  that 
indicates  the  data  is  urgent  (the  actual  Urgent  pointer  is  a 
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concern  of  the  off-loaded  TCP  interpreter,  which  is  keeping 
track  of  the  sequence  numbers)  .  When  issued  by  the  Host 
process,  the  Urgent  flag  means  the  stream  should  be  marked. 
When  issued  by  the  OPE,  it  means  the  receiver  should  go  to 
(or  remain  in)  the  Urgent  receive  mode.  If  the  flag  is  not 
set  in  the  Transmit  issued  by  the  OPE,  then  the  receiver 
should  remain  in  (or  return  to)  the  non-urgent  receive  mode. 
The  value  of  this  protocol -idiosyncratic  parameter  is  "U"  if 
the  Urgent  is  set,  or  "N"  if  it  is  not  set.  The  default 
value  for  this  parameter  is  "N”.  Since  this  parameter  is 
the  first  protocol -idiosyncratic  parameter  for  the  Transmit 
command,  it  requires  no  special  flag,  and  can  be  indicated 
using  the  flag  -pi. 

The  second  protocol -idios^Ticratic  parameter  is  the  Push 
flag.  This  parameter  is  only  issued  by  the  Host,  since 
there  is  no  Push  in  the  TCP  Deliver  event.  Its  value  is  "P" 
for  push,  or  ”N"  for  normal.  The  default  value  of  this 
parameter  is  “N” .  Its  control  flag  is  -pu. 

The  third  protocol -idiosyncratic  parameter  is  the  ULP 
timeout  action  and  value  parameter.  The  action  part 
Indicates  whether  the  offloaded  interpreter  should  abort  the 
connection  on  a  timeout  or  report  it  to  the  inboard  user. 

The  value  part  is  the  numerical  value  of  the  timeout 
interval .  The  format  used  for  this  parameter  is  the  same  as 
in  the  Begin  command,  which  is  a  single  letter  followed 
immediately  (with  no  spaces)  by  an  ASCII  number.  The  letter 
can  be  either  "R"  or  ’’A",  and  indicates  that  the  ULP  timeout 
should  cause  a  report  or  an  abort,  respectively.  The  number 
is  interpreted  to  be  the  timeout  interval  in  seconds.  The 
default  interpretation  for  this  parameter  is  its  previous 
value.  The  control  flag  for  this  parameter  is  -ul. 

1.3.3.  Examples  of  the  Command 

An  example  of  a  Transmit  command  issued  by  a  Host  process  is 
C  TR  -pi  N  P  R160  <nl>  <DATA> 

where  <DATA>  is  the  data  contained  within  the  chunk.  'This 
command  is  for  a  non-urgent  but  pushed  TCP  Send  event,  that 
also  resets  the  timeout  action  and  interval  to  Report  with  a 
value  of  160  seconds.  The  response  mode  (i.e.,  nonblocking) 
is  derived  from  the  Begin  command  and  not  effected  by 
transmit 
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An  example  of  a  Transmit  command  issued  by  the  OPE  is 
C  TR  -pi  N  <nl>  <DATA> 

where  <DATA>  is  the  data  contained  within  the  chunk.  This 
command  is  for  a  non-urgent  delivery  (presumably,  after  a 
previous  Urgent  delivery)  . 

1.4.  The  Condition  Command 

The  Condition  command  is  used  to  modify  the  transmission 
characteristics  of  the  connection.  The  parameters  that  make 
sense  to  modify  with  TCP  are  the  Transmit  Response  discipline, 
the  Type  of  Service,  and  the  Flow  Control  Advice. 

1.4.1.  Specialized  Usage 

There  is  no  usage  of  the  Condition  command  with  an  offloaded 
TCP  interpreter  that  is  particularly  specialized. 

1.4.2.  Protocol -Idiosyncratic  Parameters 

There  are  no  protocol -idiosyncratic  parameters  for  the 
condition  command  for  the  off-loaded  TCP.  It  would  be 
possible  for  the  ULP  timeout  fiction  values  to  be  changed 
with  a  condition  command.  However,  this  is  accomplished 
with  the  Transmit  command,  which  more  closely  models  the 
interface  specified  in  MIL-STD  1778.  We  propose  that  the 
condition  command  not  provide  this  capability. 

1.4.3.  Examples  of  tno  Command 

An  exanple  of  the  Condition  command  to  change  the  flow 
control  advice  for  a  connection  is 

C  CO  -fc  1  <nl> 

which  indicates  that  relatively  small  transmission  units  are 
now  expected. 
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1.5.  The  Signal  Conmand 

As  we  currently  understand  it,  TCP's  URGENT  feature  provides  an 
INband  signal  rather  than  a  true  out-of-band  signal  (and  at 
least  one  of  us  deeply  regrets  this)  .  Hie  actual  URGENT  bit  is 
sent  out-of-band,  but  it  contains  an  URGENT  pointer  which 
relates  the  URGENT  to  its  position  in  the  data  stream.  The 
actual  semantics  of  the  URGENT  is  left  to  the  higher  level 
protocol  (e.g.,  Telnet  says  to  discard  all  data  up  to  the 
URGENT  pointer)  .  Since  the  Signal  command  is  allowed  to  cross 
a  pending  Transmit  in  the  H-FP  channel,  it  would  be  potentially 
dangerous  to  implement  the  interface  to  TCP  URGENT  using  the 
Signal  command  since  the  wrong  sequence  number  could  be  used  as 
the  urgent  pointer.  Barring  persuasive  arguments  to  the 
contrarv”.  it  Is  proposed  that  Signal  should  not  be  used  with 
TCP. 


1.6.  The  Status  Command 

The  Status  command  maps  directly  into  the  TCP  Status_ event  when 
issued  by  a  Host  process.  It  is  also  used  for  the  TCP  error 
event  when  issued  by  the  OPE.  There  is  currently  some  question 
as  to  how  information  from  lower  protocol  levels  (e.g.,  ICMP 
error  messages)  should  be  reported  to  TCP  users.  When  these 
Issues  are  resolved,  there  may  be  other  uses  for  the  Status 
command.  We  solicit  other  ideas  for  the  Status  command  with 
this  report. 

1.6.1.  Specialized  Usage 

The  major  specialized  usage  of  the  Status  command  is  to 
provide  the  error  reporting  service.  This  usage  Is  a  form 
of  the  Status  generated  by  the  OPE. 

1.6.2.  Protocol -Idiosyncratic  Parameters 

When  used  as  a  TCP  Status  request  (command  issued  by  the 
Host  process) ,  there  are  no  protocol -idiosyncratic 
parameters  associated  with  the  Status  command.  The  OPE 
response  codes  the  TCP  status. 

When  used  as  a  TCP  error  r<^rt  (command  issued  by  the  OPE) , 
there  is  one  protocol -idios^n>cratic  parameter  associated 
with  the  Status  command.  It  is  an  error  description  in  the 
form  of  a  text  string.  It  requires  no  special  control  flag 
since  the  flag  -pi  is  unambiguous  and  there  are  no  other 
protocol -Idiosyncratic  parameters. 
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1.6.3.  Exanples  of  the  Command 

An  example  of  the  Status  command  issued  by  the  Host  process 
to  request  status  information  is 

C  ST  Q  <nl> 

The  status  information  is  returned  in  the  response  to  the 
status  command. 

An  example  of  the  Status  command  issued  by  the  OPE  to  report 
an  error  from  the  TCP  interpreter  is 

C  ST  R  -pi  "Connection  already  exists"  <nl> 

which  is  .Issued  when  a  TCP  open  (HFP  Begin)  is  issued  to  an 
already  opened  (foreign)  connection. 

1.7.  The  End  Command 

The  End  command  is  used  to  indicate  that  TCP  services  are  no 
longer  rec^ired.  Thus,  it  can  be  mapped  into  either  the  TCP 
Graceful  Close  or  the  TCP  Abort  events.  It  is  also  used  as  the 
TCP  Closing  response  (as  contrasted  with  the  response  by  the 
OPE  to  the  close  command) ,  when  issued  by  the  OPE . 

1.7.1.  specialized  Usage 

Because  of  the  nature  of  the  two-way  close  provided  by  TCP, 
there  is  a  pof^clbility  that  the  Host  and  the  OPE  wish  to 
gracefully  terminate  the  co;  meet  ion  at  the  same  instant.  If 
this  happens,  then  both  the  Host  and  the  OPE  would  issue  End 
commands  at  the  same  time.  To  be  prepared  for  this,  it  is 
necessary  to  make  this  the  normal  graceful  closing  sequence. 
In  other  words,  both  the  Graceful  Close  request  and  the 
Closing  response  are  mapped  to  End  commands,  and  the 
response  to  one  of  those  commands  only  indicates  that  the 
command  has  been  received  md  executed,  but  not  that  the 
connection  is  actually  fv  *  closed.  The  connection  is 
gracefully  when  h  •  End  commands  have  been  lssu*?d. 

and  both  successful  responses  have  been  received. 

With  an  abrupt  end.  a  two-way  exchange  is  not  n<*cessary. 

Only  the  Host  or  the  OPE  need  issue  it,  for  the  connection 
to  be  aborted. 
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1.7.2.  Protocol -Idiosyncratic  Parameters 

There  are  no  protocol -idiosyncratic  parameters  for  the  End 
command  used  with  TCP. 

1.7.3.  Examples  of  the  Command 

An  example  of  the  End  command  used  to  indicate  either  a  TCP 
Close  request  (from  the  Host  process)  or  TCP  Closing 
response  (from  the  OPE)  is 

C  EN  G  <nl> 

An  example  of  the  End  command  used  as  an  Abort  request  (from 
the  Host  process)  or  as  a  Terminato  ro^cnss  is 

C  EN  A  <nl> 

2.  Command  Level  Interface  to  an  Off-loaded  Telnet 

This  appendix  is  provided  to  discuss  the  use  of  the  commands 
described  in  the  body  of  this  document  to  provide  an  interface 
between  a  Host  process  and  an  off-loaded  interpreter  of  the  Telnet 
protocol . 

The  interface  described  here  is  not  based  on  a  formal  Interface. 
There  are  several  reasons  for  this,  including  the  lack  of  a  widely 
accepted  standard  interface  to  Telnet,  and  its  header less  nature. 
Conseqiiently,  the  interface  described  here  is  very  similar  to  the 
actual  Telnet  data  stream. 

2.1.  The  Begin  Coosnand 

The  Begin  c^manand  is  used  with  Telnet  to  initiate  Telnet 
connections . 

2.1.1.  Specialized  Usage 

There  are  three  major  specialized  usages  to  the  Begin 
coiBsand.  They  are  the  meaning  of  the  Mediation  Level 
parameter,  the  way  the  number  of  incoming  Telnet  connections 
are  supported,  and  the  meaning  of  the  secondary  address 
components. 

The  mediation  levfil  is  used  in  Telnet  to  control  which  of 
the  various  Telnot  activities  are  performed  by  the  OPE,  and 
which  are  controlled  by  the  Host.  *  It  has  been  determined 
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that  all  monitoring  of  the  Telnet  Socket  should  be  performed 
by  the  OPE.  Mediation  level  9,  which  is  the  default, 
indicates  the  Host  desires  to  play  no  role  in  Telnet 
operation.  Level  5  means  that  protocol -idiosyncratic 
parameters  to  this  Begin  command  indicate  which  incoming 
options  the  Host  wishes  to  handle;  all  other  options,  and 
all  NVT  translations,  are  to  be  performed  by  the  OPE.  Level 
0  indicates  that  the  Host  will  handle  all  options,  while  all 
NVT  translations  are  to  be  performed  in  the  OPE  (see  Section 
B.1.3)  . 

The  Host  can  either  accept  the  corrections  by  fielding  OPE 
generated  Begins,  or  by  issuing  passive  Begins  to  the  OPE. 
The  Host  may  wish  to  restrict  the  number  of  incoming  Telnet 
connections  that  it  will  handle  at  any  particular  time.  It 
can  do  this  by  rejecting  OPE -generated  Begins  above  a 
certain  number,  or  by  limiting  the  number  of  Host- issued 
passive  .Begins.  However,  precedence  constraints  dictate 
that  the  Host  actually  issue  additional  passive  Begins  or 
accept  additional  Begins  from  the  OPE  beyond  the  maximum 
number  it  is  normally  willing  to  support,  so  that 
hi^-priority  service  requests  can  be  accommodated,  possibly 
by  preempting  lower  priority  activities. 

The  secondary  address  conponcxit  is  used  to  refer  to  specific 
ports.  Normally,  they  are  used  only  when  the  standard  or 
default  ports  are  not  used,  such  as  special  purpose 
applications  or  testing. 

2.1.2.  Protocol -Idiosyncratic  Parameters 

The  protocol -idiosyncratic  parameters  to  the  Telnet  Begin 
comnuind  are  the  Identifiers  for  the  options  which  the  host 
wishes  to  negotiate  when  using  mediation  level  5.  On  other 
mcsdisition  levels,  these  parameters  are  not  used. 

2.1.3.  Examples  of  the  Command 

An  example  of  a  passive  Begin  for  an  outboard  Telnet 

protocol  is: 

C  BE  TEL  P  . .  5  N  'fc  0  -pi  9  <nl> 

V.'.:iere  the  parameters  are: 

TEL  Code  for  the  Tel not  Protocol 

P  Passive  Begin 
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, ,  Skip  the  Foreign  Address  Primary  Component 
5  Mediation  Level  is  5 

N  Non  Blocking  Transmits 

-fc  Skips  over  parameters  up  to  Flow  Control  Advice 

S  Small  Blocks  are  appropriate  for  Telnet 
-pi  Skips  over  parameters  to  the  Protocol  Idiosyncratic 
List  of  Options  to  be  Handled  by  the  Host. 

9  Option  Code  for  Line  Length  Option 

Here,  no  remote  address  component  was  specified,  since  the 
Host  will  accept  connections  from  any  Host.  Similarly,  no 
local  addresses  are  specified,  since  the  default  well-knovm 
socket  for  this  Host  is  to  be  used.  In  this  example,  the 
Host  specifies  it  will  handle  the  line  length  option  (number 
9)  .  Other  options  are  handled  in  tiie  Cr£. 

An  example  of  an  active  Begin  for  an  outboard  Telnet 
protocol  is: 

C  BE  TEL  A  ISIA  5  N  -fc  0  -pi  9  <nl> 

This  command  is  identical  to  the  passive  command,  except 
that  a  remote  primary  addr€»s  component  is  specified  to 
identify  the  intended  Host.  No  remote  secondary  component 
is  specified,  since  tiie  well-!ciown  socket  at  that  Host  is  to 
be  used.  No  local  secondary  address  components  are 
specified,  since  the  connection  can  originate  from  any 
available  socket  of  the  apprqprlate  type  selected  by  the 
OPE. 

2.2.  The  Transmit  Command 

The  Transmit  Command  is  uscxl  to  send  data  across  a  Telnet 
connection . 

2.2.1.  Specialized  Usage 

The  Transmit  coonand  is  used  to  transmit  data  over  the 
Telnet  connection.  There  is  one  specialized  aspect  of  the 
Transmit  coasBand  used  with  an  outboard  Telnet  interpreter. 
This  is  the  provision  of  the  Go  Aitead  feature  of  Telnet  that 
supports  half-duplex  devices. 

Co  Ahead  is  provided  as  a  protocol  idiosyncratic  parameter 
to  the  Transmit.  It  is  only  used  if  the  Host  will  support 
it,  however.  It  is  our  oelnion  that  Go  Ahead  is  probably 
not  s  proper  thing  for  the  default  case. 
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Go  Aheads  are  a  matter  bet^^een  the  Host  and  the  terminal.  It 
Is  difficult  to  offload  the  generation  of  Go  Aheads  to  the 
OPE,  since  the  OPE  is  not  really  cognizant  of  the  semantics 
of  the  comnunication  between  the  Host  and  the  terminal. 
Hence,  the  OPE  does  not  know  when  the  Host  is  done 
transmitting  and  willing  to  pass  "the  turn”  back  to  the 
terminal.  Similarly  when  the  remote  site  relinquishes 
control,  the  OPE  includes  Go  Ahead  in  its  TR. 

We  don*t  believe  this  Go  Ahead  problem  to  be  an  indictment 
against  outboard  processing.  It  merely  illustrates  that 
functionality  not  found  in  a  Host  cannot  necessarily  be 
provided  by  the  OPE.  Hence,  we  provide  this  not-^  to  the 
inplementor:  if  the  Host  cannot  generate  tiie 
protoeol-idiosyTiCrstic  Go  Ahead  parameter .  then  the  DO 
Suppress  Go  Ahead  must  be  issued  immediately  after  the 
connection  is  established. 

2.2.2.  Protocol  Idiosyncratic  Parameters 

The  protocol  idiosyncratic  parameter  is  the  Go  Ahead 
indicator.  When  present,  the  character  ”G"  is  used  to  mean 
the  Go  Ahead  can  be  sent  t>  the  other  end  of  the  connection, 
but  only  after  the  data  associated  with  that  Transmit 
command  is  sent.  When  the  character  is  any  other  value,  or 
Is  absent,  the  Go  Ahead  should  not  be  sent. 

2.2.3.  Examples  of  the  Command 

An  example  of  the  Transmit  command  is: 

C  TR  -pi  G  <nl>  <DATA> 

With  this  command,  the  Co  Ahead  is  passed  to  the  other  side 
after  the  data  is  sent. 

2.3.  The  Condition  Coamand 

The  Condition  command  is  used  with  Telnet  to  modify  the 
Trar*smiS3ier.  characteristics  and  to  enable  or  disable  Telnet 
options  on  a  Telnet  connection. 

2.3.1.  specialized  Usage 

The  Condition  command  takes  on  specialized  usage  with 
Telner.  in  atfclltion  to  It*  normal  usage.  It  is  used  to 
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control  the  option  selection  and  negotiation  process,  when 
such  selection  is  performed  by  the  Host  (currently,  this  is 
done  at  mediation  levels  5  and  1,  but  not  at  level  9)  . 

A  set  of  protocol -idiosyncratic  parameters  has  been  defined 
for  this  purpose.  They  are  based  heavily  on  the  Telnet 
negotiation  and  subnegotiation  mechanisms.  For  siaple 
negotiations  there  are  two  parameters,  a  negotiation  typo 
(from  the  set  {DO,  DWT,  WILL,  WONT})  followed  by  the  code 
(numeric)  or  name  (symbolic)  for  the  desired  cation.  Ihe 
codes  for  the  options  are  identified  below.  A  basic 
difference  between  the  H-FP  interface  to  Telnet  and  the 
internal  Telnet  protocol  is  that  additional  parameters  are 
included  with  the  request  (DO  or  WILL)  .  The  Telnet  protocol 
subnegotiation  is  used  internally  to  communicate  that 
information  in  the  Telnet  data  stream.  Option-specific, 
protocol -idiosyncratic  parameters  are  used  for  these 
additional  parameters. 

Both  the  Host  and  the  OPE  can  issue  these  Condition 
commands.  When  issued  by  the  Host,  it  means  the  user  wishes 
to  «ud>le  or  disable  a  particular  option.  The  OPE  proceeds 
to  issue  the  appropriate  negotiation  commands  (i.e.,  lAC 
<D0>  <code>)  in  the  Telnet  data  stream.  When  the  results  of 
the  option  negotiation  are  available,  a  response  is 
generated  by  the  OPE.  For  the  types  DO  and  WILL,  a  000 
Response  Indicates  the  appropriate  acceptance  (WILL  or  00, 
respectively) .  A  nonzero  Response  code  may  indicate 
negotiation  failure  or  negotiation  rejection  (among  other 
things)  .  For  the  types  DONT  and  WONT,  a  000  Response 
indicates  the  option  will  be  disabled.  A  negotiation 
rejection  should  not  be  expected  in  those  cases. 

When  the  Condition  command  is  issued  by  the  OPE,  it  means 
the  other  end  of  the  connection  is  negotiating  a  change. 

Here  the  response  from  the  Host  indicates  the  Host's  deslrod 
action  for  the  option  negotiation.  Again,  valid  requests  to 
disable  ^tions  (DONT  and  WONT  requests)  should  always  get  a 
000  Response. 

2.3.2.  Protocol -Idlosyncravj.^  Parameters 

There  are  two  protocol-ldiosyrcratlc  parameters  for  primary 
negotiation  using  the  Condition  command.  These  are  the 
negotiation  type  and  the  option  code.  The  negotiation  type 
is  one  of  the  set  of  {DO,  DONT.  WILL,  V#0NT>.  The  cption 
code  is  a  THSMric  value  used  to  identify  the  particular 
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option  being  negotiated.  The  values  for  these  codes  are 
indicated  here,  but  are  identical  to  the  codes  used  in  the 
actual  Telnet  negotiation.  The  codes  are: 


Cation  Name  Cation  Code 

Short  Name 

Transmit  Binary 

0 

Binary 

Echo 

1 

Echo 

Suppress  Go-Ahead 

3 

SuppressGA 

Af^roximate  Message  Size 

4 

NAMS 

Status 

5 

Status 

Timing  Mark 

6 

TiroingMark 

RCTE 

7 

RCTE 

Line  Length 

8 

LineLength 

Page  Size 

9 

PageSize 

Carriage  Return  Disp 

10 

CRDisp 

Horizontal  Tabstops 

11 

HTabStops 

Horizontal  Tab  Disp 

12 

KTabDisp 

Formfeed  Disposition 

13 

FFDisp 

Vertical  Tabstops 

14 

VTabStops 

Vertical  Tab  Disposition 

15 

VTabDisp 

Linefeed  Disposition 

16 

LFDisp 

Extended  ASCII 

17 

ExASCII 

Logout 

18 

Logout 

Data  Entry  Terminal 

20 

DET 

Terminal  Type 

24 

TermType 

Extended  options  list 

255 

ExOptions 

Options  not  listed  here  may  of  course  be  used.  The  code 
number  should  be  the  same  as  the  option  code  used  in  Telnet 
negotiation. 

2. 3. 2.1.  SinpXe  Options 


Options  that  do  not  require  additional  parameters  use  the 
simple  negotiation  mechanisms  described  briefly  above  and 
in  greater  detail  in  the  Telnet  documentation.  No 
additional  parameters  are  required,  ""hese  options 
include  the  Transmit  Binary.  Echo.  Suppress  Go  Ahead. 
Status,  Timing  Mark,  and  Logout  options. 


2. 3. 2. 2.  Approximate  Message  Size  Option 


The  Approximate  Message  Size  option  requires  two 
parameters.  The  first  indicates  whether  the  tipproximate 
message  size  being  negotiated  applies  to  the  local  or  the 
remote  end  of  the  connection.  DS  means  the  size  applies 
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to  the  sender  of  the  command  (i.e.,  if  the  Host  Issues 
the  command,  DS  means  the  local  end  of  the  connection; 
if  issued  by  the  OPE,  DS  means  the  remote  end  of  the 
connection)  .  DR  means  the  size  applies  to  the  receiver 
of  the  command  (i.e.,  if  the  Host  issues  the  command,  DR 
means  the  remote  end;  if  issued  by  the  OPE,  DR  means  the 
local  end  of  the  connection) .  This  convention  is 
consistent  with  the  Telnet  subnegotiation  mechanisms. 

The  second  character  is  an  ASCII  encoded  numeric  value, 
which  is  a  character  count  of  the  message  size. 

2.3.3.  Line  Width  and  Page  Size  Options 

The  Line  Width  and  Page  Size  Options  require  two  additional 
parameters.  The  first  indicates  whether  the  line  width  or 
page  size  being  negotiated  applies  to  the  local  or  the 
remote  end  of  the  connection,  and  uses  the  DS  and  DR 
convention  described  above.  The  second  parameter  is  an 
ASCII  encoded  numeric  value,  which  is  interpreted  as  follows 
(assuming  the  Condition  command  was  issued  by  the  Host)  : 

0  The  Host  requests  that  it  handle  length  or  size 

considerations  for  the  direction  indicated  by 
the  first  parameter. 

1  to  253  The  Host  requests  that  the  remote  end  handle 
the  size  or  length  considerations  for  the 
direction  Indicated  by  tlya  first  parameter,  but 
suggests  that  the  value  indicated  be  used  as 
the  size  or  length. 

254  The  Host  requests  that  Che  remote  end  handle 
the  size  or  length  considerations  for  the 
direction  indicated  by  the  first  parameter,  but 
suggests  that  the  size  or  length  be  considered 
to  be  infinity. 

255  The  Host  requests  that  the  remote  end  handle 
the  tabstop  considerations,  and  suggests 
notiling  about  what  the  value  should  be. 

If  the  Condition  command  is  Issued  by  "die  OPE‘,  then  the 
roles  of  the  Host  and  the  remote  end  are  reversed. 
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2.3.4.  Tabstop  Options 

The  Horizontal  and  Vertical  Tabstops  options  require  two 
option  specific  parameters.  The  first  is  either  DR  or  DS, 
as  was  described  previously.  The  second  is  a  list  of  one  or 
more  ASCII  encoded  numeric  values  separated  by  spaces  which, 
assuming  the  Condition  command  is  issued  by  the  Host,  are 
individually  interpreted  as: 

0  The  Host  requests  that  it  handle  tabstops  for 

the  direction  indicated  by  the  first  parameter. 

1  to  250  The  Host  requests  that  the  remote  end  handle 
the  tabstop  considerations  for  the  direction 
indicated  by  the  first  parameter,  but  suggests 
that  the  value  (s)  indicated  should  be  used  as 
the  tabstops. 

255  The  Host  requests  that  the  remote  end  handle 

the  tabstop  considerations  for  the  direction 
Indicated  by  the  first  parameter,  and  suggests 
nothing  about  what  the  value  should  be. 

If  the  Condition  command  is  issued  by  the  OPE,  then  the 
roles  of  the  Host  and  the  remote  end  are  reversed. 

2.3.5.  Character  Disposition  Cations 

The  Carriage  Return  Disposition  option,  the  Horizontal  Tab 
Disposition  cation,  the  Formfeed  Disposition  option,  the 
Vertical  Tab  Disposition  option,  and  the  Linefeed 
Disposition  option  are  all  considered  character  disposition 
options  from  the  perspective  of  H-FP.  Two  option- ^>eciflc 
parameters  are  requircKi  for  the  character  disposition 
options.  The  first  is  the  DR  or  DS  code,  which  was 
described  previously.  The  second  is  a  single  ASCII  encoded 
numeric  value,  which  is  interpreted  as  (assuming  that  the 
Host  issued  the  Condition  command) : 

0  The  Host  requests  that  it  handle  the  character 

disposition  for  this  connection. 

1  to  250  The  Host  suggests  that  the  remote  end  handle 
the  character  disposition  considerations,  but 
suggests  that  the  value  indicated  should  be 
taken  as  the  number  of  nulls  which  should  bo 
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inserted  in  the  data  stream  following  the 
particular  format  character  being 
subnegotiated . 

251  The  Host  suggests  that  the  remote  end  handle 
the  character  disposition  considerations,  but 
reconniends  that  it  replace  the  character  with 
some  simplified  character  similar  to  but  not 
identical  with  it  (e.g.,  replace  a  tab  with  a 
space,  or  a  formfeed  with  a  newline)  . 

252  The  Host  suggests  that  the  remote  end  handle 
the  character  disposition  considerations,  but 
recommends  that  it  discard  the  character. 

253  Tlie  Host  suggests  that  the  remote  end  handle 
the  character  disposition,  but  recommends  that 
the  effect  of  the  character  be  simulated  using 
other  characters  such  as  spaces  or  linefeeds. 

254  The  Host  suggests  that  the  remote  end  handle 
the  character  disposition  considerations,  but 
recommends  that  it  wait  for  additional  data 
before  sending  more  data. 

255  The  Host  suggests  that  the  remote  end  handle 
the  tabstop  considerations,  and  suggests 
nothing  about  what  the  value  should  be. 

Some  of  the  codes  between  251  and  254  are  not  used  with  some 
character  disposition  options.  Refer  to  the  ARPANET 
documentation  for  additional  details. 

If  the  Condition  command  is  issued  by  the  OPE,  then  the 
roles  of  the  Host  and  the  remote  end  are  reversed. 

2 . 3 . 5 . 1 .  RCTE  Option 

The  Remote  Controlled  Transmission  and  Echoing  option 
rec^res  parameters  to  indicate  the  sets  of  break 
characters  and  transmit  characters.  There  are  two 
option -idiosyncratic  parameters  for  RCTE.  The  first  Is  a 
list  of  the  character  classes  that  make  \jp  the  set  of 
break  characters,  as  defined  in  the  RCTE  documentation. 
The  second  is  a  list  of  character  classes  that  make  up 
the  set  of  transmit  characters,  as  ceflned  in  the  RCTE 
documentation.  Since  the  two  classes  are  optional  and 


Lilienkamp  &  Mandell  &  Padlipsky 


[Page  50] 


MILITARY  STANDARDS:  HFE 


RFC  929  DecemJoer  1984 

Proposed  Host-Front  End  Protocol 


can  be  of  arbitrary  length,  it  is  necessary  to  precede 
each  list  with  a  -be  (break  characters)  or  -tc  (transmit 
characters)  .  The  character  classes  are  defined  as 

1  Upper  Case  Letters  A  throuc^  Z 

2  Lower  Case  Letters  a  through  z 

3  Digits  0  through  9 

4  Format  effectors  <BS>  <CR>  <LF>  <FF>  <HT>  <VT> 

5  Non- format  control  codes,  plus  <ESC>  and  <DEL> 

6  Punctuation 

7  Grouping  {C(<^)]} 

8  Misc 

9  <space> 

2. 3.5.2.  Extended  Option  List 

The  Extended  Option  List  option  requires  a  parameter  to 
carry  the  number  of  the  option  on  the  coctended  list. 

There  is  thus  one  option  specific  parameter  to  the 
Condition  command  when  used  for  this  purpose,  which  is 
the  number  of  the  option  on  the  extended  option  list.  It 
can  be  expressed  in  ASCII  using  an  octal,  decimal,  or 
h€ucadecimal  format. 

2. 3. 5. 3.  Terminal  Extension  Options 

The  Extended  ASCII,  SUPDUP,  and  Data  Entry  Terminal 
options  of  Telnet  were  all  attempts  to  extend  the  basic 
capabilities  of  the  Telnet  data  stream  beyond  the  simple, 
scroll  mode  terminal  model  that  was  the  basis  of  the 
original  Telnet  design. 

All  of  these  options  have  limitations  to  their 
effectiveness.  The  Extended  ASCII  option  lacks  a 
standardized  interpretation  of  the  bit  patterns  into 
extended  ASCII  characters.  The  SUPDUP  effort  was 
actually  an  independent  mode  where  a  different  virtual 
terminal  protocol  was  used,  and  the  option  was  there 
merely  to  switch  to  and  from  this  protocol.  The  Data 
Entry  Terminal  option  requires  the  excessive  overhead  of 
subnegotiation  for  each  use  of  extended  features.  All  of 
these  options  lack  the  more  valuable  asset  of  widespread 
implcnnentation  and  use. 

The  way  these  options  should  be  handled  is  net  detailed 
in  this  appendix.  It  is  clear  that  the  Condition  command 
could  be  used  for  initiating  and  terminating  the  use  of 
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these  options.  The  actual  transmission  of  characters 
related  to  the  extended  terminal  features  should  be 
provided  by  the  Transmit  command,  either  as  part  of  the 
normal  Host-to-OPE  data  stream  or  by  using 
protocol - idiosyncratic  parameters . 

A  more  recent  option,  the  Terminal  Type  option,  should  be 
mentioned  here.  It  permits  one  end  of  a  connection  to 
request  information  about  the  terminal  at  the  other  end 
or  send  information  about  the  terminal  at  the  local  end. 
This  is  convenient  for  systems  that  provide  a  wide 
variety  of  terminal  support,  but  it  clearly  does  not 
follow  the  model  of  reducing  the  MxN  problem  by  use  of  a 
virtual  terminal.  Its  use  is  very  straightforward  in  the 
H-FP  context.  It  only  requires  sending  terminal  type 
to  the  other  end,  and  activating  the  Binary  Transmission 
Option. 


2. 3.5.4.  Status  Option 

The  Status  option  is  enabled  using  the  negotiation 
mechanism  of  Telnet.  However,  the  means  to  transfer 
status  information  between  OPE  and  the  Host  is  provided 
via  the  Status  comnand.  Therefore,  details  of  status 
negotiation  are  irrelevant  to  the  interface  to  the 
outboard  Telnet. 

2.3.6.  Exanples  of  the  Comnand 

The  following  exasple  shows  the  command  issued  by  a  Host  to 
the  OPE,  requesting  that  the  OPE  negotiate  with  the  other 
side  so  that  remote  echo  is  performed. 

C  CO  -pi  DO  3  <nl> 

The  numeral  1  is  the  option  code  for  ECHO  from  the  table 
al>ove.  All  of  the  simple  options  listed  above  use  this  same 
basic  format. 

The  options  with  additional  parameters  use  straightforward 
extensions  of  this  syntax.  For  example,  a  possible  usage  of 
Condition  by  the  Host  to  set  the  approximate  message  size 
is: 


C  CO  -pi  DO  4  DS  1024 
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2.5.  The  Status  Coimnand 

The  Status  connand  Is  used  with  Telnet  to  obtain  information 
about  the  Telnet  connection  and  the  options  in  effect. 

2.5.1.  Specialized  Usage 

The  Status  command  has  one  i^Decialized  aspect  vihen  used  to 
Interface  to  an  outboard  Telnet  interpreter.  That  is  to 
send  and  receive  the  Telnet  Protocol  status  request 
subnegotiation  mcMisage  to  and  from  the  data  stream.  In 
order  to  invoke  the  status  command  for  this  purpose, 
ho%fever,  the  user  must  have  previously  issued  the  Condition 
Status  connand,  which  causes  the  ability  to  request  status 
to  be  negotiated.  The  OPE,  yAy&rx  it  receives  a  valid  Status 
request  command,  immediately  responds  to  the  user  indicating 
the  status.  The  OPE  can  issue  a  status  to  request  the 
Hbst's  negotiated  positions. 

2.5.2.  Protocol -Idiosyncratic  Parameters 

There  are  no  protocol -idiosyncratic  parameters  to  the  Status 
query  command.  The  Status  Response  command  has  a  single 
protocol -idiosyncratic  parameter.  It  is  an  ASCII  string 
containing  the  status  of  the  various  options  (not  at  their 
default  values) . 

2.5.3.  Examples  of  the  Command 

An  example  of  a  Status  Query  command  is; 

C  ST  Q 

An  exasple  of  a  Status  Re^onse  command  is: 

F  ST  R  '‘WILL  ECHO  DO  SUPPRESS -GO-AHEAD 
L  WILL  STATUS  DO  STATUS”  <nl> 

In  the  previous  example,  note  the  opening  quote  is  in  the 
first  chunk,  and  the  closing  quote  is  in  the  last  chunk. 
This  technique  permits  parameters  to  ipan  chunk  boundaries. 
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The  4  is  the  Option  Code  for  the  Approximate  Message  Size 
^tion,  the  DS  indicates  that  Host's  message  size  i^hould  be 
set,  and  1024  is  the  desired  size. 

2.4.  The  Signal  Command 

The  Signal  command  is  used  with  Telnet  to  provide  the  Telnet 
Interrupt  Process  and  Abort  Output  services. 

2.4.1.  specialized  Usage 

The  Signal  command  is  used  with  an  outboard  Telnet 
interpreter  to  interface  to  the  Telnet  synch  mechanism. 

This  mechanism  is  used  with  a  protocol -idiosyncratic 
parameter,  which  indicates  what  particular  comnand  is  being 
^'synched."  It  is  esqpected  that  normally,  this 
mechanism  will  only  be  used  with  the  Interrupt  Process  and 
Abort  Output  Telnet  signals.  When  the  Signal  command  is 
issued  by  the  Host,  it  goes  throu^  the  Channel 
(out-of-band)  to  the  OPE,  where  the  Telnet  interpreter 
issues  the  correiqponding  Telnet  signal  and  synch  seq^iAsnce. 
When  such  a  sequence  is  received  by  the  OPE,  it  ioMClately 
issues  a  Signal  to  the  Host.  It  is  expected  that  a  Host  or 
OPE  would  not,  in  general,  reject  the  Signal  coamand  unless 
it  is  bedly  formed. 

2.4.2.  Protocol -Idiosyncratic  Parameters 

The  Telnet  protocol -idiosyncratic  parameter  used  with  the 
command  identifies  which  Telnet  signal  is  begin 
issued.  Normally,  it  would  have  the  value  of  either  "IP"  or 
"AO",  for  Interrupt  Process  or  Abort  Output.  If  absent,  the 
default  value  is^'IP". 

2.4.3.  Exapples  of  the  Cofanand 

An  example  of  a  Telnet  Signal  Command  (in  this  case,  to  send 
an  Interrupt  Process  signal)  is: 

C  ST  IP  <nl> 
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2.6.  The  End  Coanand 

The  End  comnand  is  used  to  terminate  the  Telnet  connection, 
either  gracefully  or  abruptly. 

2.6.1.  Specialized  Usage 

The  graceful  termination  of  a  Telnet  requires  End  commands 
to  be  issued  by  both  the  Host  and  the  OPE.  This  specialized 
usage  is  Identical  to  that  of  the  outboard  TCP  interface, 
however. 

2.6.2.  Exanples  of  the  Command 
An  example  of  the  graceful  End  command  is: 

C  EN  C  <nl> 

The  abrupt  End  command  Is  similar. 

2.7.  The  No-op  Coomand 

The  No-op  command  is  used  with  Telnet  so  the  Host  can  determine 
if  the  OPE  is  active,  and  vice  versa. 

2.7.1.  Specialized  Usage 

The  No-op  coimand  has  one  specialized  usage  when  offloading 
Telnet.  This  is  to  provide  the  Telnet  Are  You  There  (AYT) 
feature.  When  an  (AYT)  message  is  received  by  the  CPE.  It 
issues  a  No-op  command  to  the  Host.  Upon  receiving  the 
response  from  the  Host,  the  appropriate  response  is  sent 
back  in  the  data  stream. 

2.7.2.  Protocol  Idiosyncratic  Parameters 

There  are  no  protocol -idiosyncratic  parameters  to  the  No-op 
command. 

2.7.3.  Exanples  of  the  Command 
An  exasple  of  the  No-op  command  is: 

C  NO  <nl> 

I 

r 


V- V 


Lilienkamp  6  Mandell  6  Padlipsky 


55] 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE  1985 


RFC  929  December  1984 

Proposed  Host-Front  End  Protocol 

3.  FTP  Offloading 
TBS 

4.  Mail  Offloading 
TBS 

5.  Whatever  Offloading 
TBS 

Where  TBS  nomirilly  *  To  Be  Supplied,  but  really  means:  We’ll  argue 
throu^  these  once  ve  get  sufficiently  positive  feedback  on  the 
othars  (and  on  the  H-FP  as  a  vhole) . 


« 


Lilienkanp  St  ftendell  St  Padlipsky 


[Page  56 


MILITARY  STANDARDS:  ICMP 


J.  Postel 
ISI 

September  1981 


INTERNET  CONIItOL  MESSAGE  PROTOCOL 

DARPA  INTERNET  PROGRAM 
PROTOCOL  SPECIFICATIC»I 


Network  Working  Group 
Request  for  Comments:  792 

Updates:  RFCs  111.  760 
Updates:  lENs  109,  128 


Introduction 

The  Internet  Protocol  (IP)  [1]  is  used  for  host*to*host  datagram 
service  in  a  system  of  interconnected  networks  called  the 
Catenet  [2] .  The  network  connecting  devices  are  called  Gateways. 
These  gateways  comnunicate  between  themselves  for  control  purposes 
via  a  Gateway  to  Gateway  Protocol  (GGP)  [3,4].  Occasionally  a 
gateway  or  destination  host  will  connunicate  with  a  source  host,  for 
exanple,  to  report  an  error  in  datagram  processing.  For  such 
purposes  this  protocol,  the  Internet  Control  Message  Protocol  (lO^) , 
is  used.  ICMP,  uses  the  basic  support  of  IP  as  if  it  were  a  hi^ier 
level  protocol,  however,  ICMP  is  actually  an  integral  part  of  IP.  and 
must  be  ixoplenented  by  every  IP  module. 

ICMP  messages  are  sent  in  several  situations:  for  exaaple,  when  a 
datagram  cannot  reach  its  destination,  when  the  gateway  does  not  have 
the  buffering  c^>acity  to  forward  a  datagram,  and  the  gateway 
can  direct  the  host  to  send  traffic  on  a  shorter  route. 

The  Internet  Protocol  is  not  desi^ied  to  be  absolutely  reliable.  The 
purpose  of  these  control  messages  is  to  provide  feedback  about 
problems  in  the  communication  environment,  not  to  make  IP  reliable. 
There  are  still  no  guarantees  that  a  datagram  will  be  delivered  cr  a 
control  message  will  be  returned.  Socm  datagrams  may  still  be 
undelivered  without  any  report  of  their  loss.  The  higher  level 
protocols  that  use  IP  must  iaplement  their  own  reliability  procedures 
if  reliable  communication  is  required. 

The  ICMP  messages  typically  report  errors  in  the  processing  of 
datagrams.  To  avoid  the  infinite  regress  of  messages  about  messages 
etc.,  no  IQfi’  messages  are  sent  about  ICMP  messages.  Also  ICMP 
messages  are  only  sent  about  errors  in  handling  fragaent  zero  of 
fragemented  datagrams.  (Fragaent  zero  has  the  fragaent  offeset  equal 
zero)  . 
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Message  Formats 

ICMP  messages  are  sent  using  the  basic  IP  header.  The  first  octet  of 
the  data  portion  of  the  datagram  is  a  ICMP  type  field;  the  value  of 
this  field  determines  the  format  of  the  reoiaining  data.  Any  field 
labeled  *'unusad"  is  reserved  for  later  extensions  and  must  be  zero 
when  sent,  but  receivers  should  not  use  these  fields  (except  to 
include  them  in  the  checksum) .  Unless  otherwise  noted  under  the 
individual  format  descriptions,  the  values  of  the  internet  header 
fields  are  as  follo%is: 

Version 

4 

IKT. 


Internet  header  length  in  32*bit  words. 

Type  of  Service 
0 

Total  Length 

Length  of  internet  header  and  data  in  octets. 

Identification,  Flags.  Fragment  Offset 
Used  in  frageentation,  see  [1) . 

Tine  to  Live 

Tine  to  live  in  seconds;  as  this  field  is  decrenented  at  each 
machine  in  which  the  datagram  is  processed,  the  value  in  this 
field  should  be  at  least  as  great  as  the  number  of  gateways  %^lch 
this  datagran  will  traverse. 

Protocol 


'X’. 


ICM?  s  1 
Header  Checks'«mi 

The  16  bit  one's  cooplenent  of  the  one's  complement  sun  of  all  16 
bit  words  in  the  header.  For  coeputing  the  checksum,  the  checksum 
field  should  be  zero.  This  checksum  may  be  replaced  In  the 
future . 


i 


V 


Die  «;ddress  of  the  gateway  or  host  that  cooposes  the  ICMP  message. 
Unless  otherwise  noted,  this  can  be  any  of  a  gateway's  addresses. 

Destination  Address 

The  address  of  the  gateway  or  host  to  the  message  should  be 

sent. 


a 
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Destination  Unreachable  Message 

0  12  3 

01234567890123456789012345678901 

I  Type  i  Code  |  Checksum  j 

I  unused  I 

I  Internet  Header  +  64  bits  of  Original  Data  Datagram  | 

IP  Fields: 

Destination  Address 

The  source  network  and  address  from  the  original  datagram's  data. 
ICMP  Fields: 

Ti.pe 

3 

Code 

0  >  net  unreachable; 

1  *  hoot  xmreachible; 

2  »  protocol  unreachable; 

3  »  port  unreachable; 

4  -  fragmentation  needed  and  DE  set; 

5  =  source  route  failed. 

Checksum 

The  checksum  is  the  16-blt  ones's  conplement  of  tlim  one's 
cooplemant  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  cooputlng  the  checksum  .  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  in  the  future. 

Internet  Header  64  bits  of  Data  Datagram 

The  Internet  header  plus  the  first  64  bits  of  the  original 
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datagram's  data,  nils  data  is  used  by  the  host  to  match  the 
message  to  the  appropriate  process.  If  a  higher  level  protocol 
uses  port  numbers,  they  are  assumed  to  be  in  the  first  64  data 
bits  of  the  original  datagram's  data. 

Description 

If,  according  to  the  information  in  the  gateway's  routing  tables, 
the  network  specified  in  the  internet  destination  field  of  a 
datagram  is  unreachable,  e.g.,  the  distance  to  the  network  is 
infinity,  the  gateway  may  send  a  destination  unreachable  message 
to  the  internet  source  host  of  the  datagram.  In  addition,  in  some 
networks,  the  gateway  may  be  able  to  determine  if  the  internet 
destination  host  is  unreachable.  Gateways  in  these  networks  may 
send  destination  unreachable  messages  to  the  source  host  when  the 
destination  host  is  unreachable. 

If.  in  the  destination  host,  the  IP  module  cannot  deliver  the 
datagram  because  the  indicated  protocol  module  or  process  port  is 
not  active,  the  destination  host  may  send  a  destination 
unreachable  message  to  the  source  host. 

Another  case  is  when  a  datagram  must  be  fragmented  to  be  forwarded 
by  a  gateway  yet  the  Don't  Fragment  flag  is  on.  In  this  case  the 
gateway  must  discard  the  datagram  and  may  return  a  destination 
unreachable  message. 

Codes  0,  1,  4,  and  5  may  be  received  from  a  gateway.  Codes  2  and 
3  may  be  received  from  a  host. 
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Time  Exceeded  Message 

0  12  3 

01234567890123456789012345678901 

I  Type  I  Code  |  Checksum  | 

+-+-+-+-+-+-+-+-+-+-+-+--»--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I  unused  i 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--f-+-+-+— 

I  Internet  Header  64  bits  of  Original  Data  Datagram  | 


IP  Fields: 

Destination  Address 

The  source  network  and  address  from  the  original  datagram's  data. 
ICMP  Fields: 

Typo 

11 

Code 

0  s  time  to  live  exceeded  in  transit; 

1  -  fragment  reassembly  time  exceeded. 

Checksum 

The  checksum  is  the  16-bit  ones's  cooplement  of  the  one's 
conplenent  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  collating  the  checksum  ,  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  in  the  future. 

Internet  Header  **’  64  bits  of  Data  Datagram 

The  internet  header  plus  the  first  64  bits  of  the  original 
datagram's  data.  This  data  is  used  by  the  host  to  match  the 
message  to  the  appropriate  process.  If  a  higher  level  protocol 
uses  port  numbers,  they  are  assumed  to  be  in  the  first  64  data 
bits  of  the  original  datagram's  data. 

Description 

If  the  gateway  processing  a  datagram  finds  the  time  to  live  field 
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is  zero  it  must  discard  the  datagram.  The  gateway  may  also  notify 
the  source  host  via  the  time  exceeded  message. 

If  a  host  reassembling  a  fragmented  datagram  cannot  conplete  the 
reassembly  due  to  missing  fragments  within  its  time  limit  it 
discards  the  datagram,  and  it  may  send  a  time  exceeded  message. 

If  fragment  zero  is  not  available  then  no  time  exceeded  need  be 
sent  at  all. 

Code  0  may  be  received  from  a  gateway.  Code  1  may  be  received 
from  a  host. 
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Parameter  Problem  Message 


0  12  3 

01234567890123456789012345678901 

+  -  +  -4.-4.-  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  --{  +  -  +  -  +  -  +  -+-  +  -  +  -  +  -  +  -  +  ~  + 

I  Type  1  Code  {  Checksum  I 

♦ +  -  +  -  +  -  +  -  +  +  -  +  -  +  -  +  -  +  -  +  -4 -  +  -  +  -  +  -  +  -  +  +  -  +  -  +  -  +  «  +  -  +  +  -  + 

'  Pointer  I  unused  * 


Intfjmet  Header  +  64  bits  of  Original  Data  Datagram 


IP  Fields: 


Destination  Address 


The  source  network  and  address  from  the  original  datagram's  data 


ICMP  Fields: 


0  s  pointer  indicate  the  error. 


Checksum 


The  checksum  is  the  16>bit  ones's  cooplaraent  of  the  one's 
coqplenent  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  computing  the  checksum  ,  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  in  the  future. 


Pointer 


If  code  »  0,  identifies  the  octet  where  an  error  was  ctetected. 


Internet  Header  ^  64  bits  of  Data  Datagram 


The  internet  header  plus  the  first  64  bits  of  the  original 
datagram's  data.  This  data  is  used  by  the  host  to  match  the 
message  to  the  appropriate  process.  If  a  hi^^r  level  protocol 
uses  port  numbers «  they  are  assumed  to  be  in  the  first  64  data 
bits  of  the  original  datagram's  data. 
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Description 

If  ttm  gateway  or  host  processing  a  datagram  finds  a  problem  with 
the  header  parameters  such  that  it  cannot  complete  processing  the 
datagram  it  must  discard  the  datagram.  One  potential  source  of 
such  a  problem  is  with  incorrect  arguments  in  an  option.  The 
gateway  or  host  may  also  notify  the  source  host  via  the  parameter 
problem  message.  This  message  is  only  sent  if  the  error  caused 
the  datagram  to  be  discarded. 

The  pointer  identifies  the  octet  of  the  original  datagram -s  header 
where  the  error  was  detected  (it  may  be  in  the  middle  of  an 
option)  .  For  example,  1  indicates  something  is  wrong  with  the 
T\pe  of  Service,  and  (if  there  are  options  present)  20  indicates 
something  is  wrong  with  the  type  code  of  the  first  option. 

Code  0  may  be  received  from  a  gateway  or  a  host. 
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Source  Quench  Message 

0  12  3 

0123456789012345678901234S678901 

+  -  +  -  +  -4.- +  -  +  -  +  -  +  -4. -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  - +  -  +  -  +  -  +  -  +  -  +  -  +  - +  -  +  -  +  -  + 

j  Type  I  Code  |  Checksum  I 

4.- 4.-4.-4.-4.-4.-4.-4.-4.«4.-4i-4>->f-  +  -  +  -  +  ->f -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  +  - +  -  +  -  +  -  +  -  +  -  + 

I  unused  I 

4.-4.-4.-4.-4.-4.-4.-4.-4--4.-4.-4--  +  -  +  -  +  -4>-  +  -+~‘f-  +  ~  +  -  +  -  +  -  +  -+-  +  -  +  -  +  -  +  -  +  -  +  -  +  -  + 

I  Internet  Header  +  64  bits  of  Original  Data  Datagram  | 

4.-4.  -  +  -  +  -4.-4.- 4.-4.-4.-4--4.-^-4--  + -  +  -  +  -  +  -  +  - +  -  +  ~  +  -  +  -  +  -  +  -+-  + -  +  -  +  -  +  »  +  -4‘-  +  -  + 

IP  Fields: 

Destination  Address 

The  source  network  and  address  of  the  original  datagram *s  data. 
ICMP  Fields: 

Type 


4 

Code 

0 

Checksum 

The  checksum  is  the  16*bit  ones's  complement  of  the  one's 
complement  sum  of  the  ICKI*  message  starting  with  the  ICMP  Type. 
For  computing  the  checksimi  «  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  in  the  future. 

Internet  Header  ^  64  bits  of  Data  Datagram 

The  internet  header  plus  the  first  64  bits  of  the  original 
datagram's  data.  This  data  is  used  by  the  host  to  match  the 
message  to  the  ^^propriate  process.  If  a  higher  level  protocol 
uses  port  nuoters.  they  are  assumed  to  be  in  the  first  64  data 
bits  of  the  original  datagram's  data. 

Description 

A  gateway  may  discard  internet  datagrams  if  it  does  not  have  the 
buffer  space  needed  to  queue  the  datagrams  for  output  to  the  next 
network  on  the  route  to  the  destination  network.  If  a  gateway 
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discards  a  datagram^  It  xoay  send  a  source  quench  message  to  the 
Internet  source  host  of  the  datagram.  A  destination  host  may  also 
send  a  source  quench  message  if  datagrams  arrive  too  fast  to  be 
processed.  The  source  quench  message  is  a  request  to  the  host  to 
cut  back  the  rate  at  which  it  is  sending  traffic  to  the  internet 
destination.  The  gateway  may  send  a  source  quench  message  for 
every  message  that  it  discards.  On  receipt  of  a  source  quench 
message,  the  sourcj  host  should  cut  back  the  rate  at  which  it  is 
sending  traffic  to  the  specified  destination  until  it  no  longer 
receives  source  quench  messages  fr^a  the  gateway.  The  source  host 
can  then  gradually  increase  the  rate  at  which  it  sends  traffic  to 
the  destination  until  it  again  receives  source  quench  messages. 

The  gateway  or  host  may  send  the  source  quench  message  when  it 
approaches  its  capacity  limit  rather  than  waiting  until  the 
capacity  is  exceeded.  This  means  that  the  data  datagram  which 
triggered  the  source  quench  message  may  be  delivered. 

Code  0  may  be  received  from  a  gateway  or  a  host. 
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Redirect  Message 

0  12  3 

01234567890123456789012345678901 

4.-4.- 4-- ^ -4.- 4.-4.- -4 4- -■♦•-<♦--4--+ -4- 

I  Type  )  Code  t  Checksum  | 

4-4-4-4-4-4-4-4--4--4--4--4--4--4--4--4--4»-4»-4»-4»-4-4-4-4-4--4’-4— 4--4--'4---f-‘  +  -4 

I  Gateway  Internet  Address  i 

4-4«4-4-4-4..4-4--4--4--4--4—4--4—4--4‘—4-4»-4»-4»-4-4-4-4-4—4--4--4--4--4— 4-4-4 

I  Internet  Header  >  64  hits  of  Original  Data  Datagram  i 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 


IP  Fields: 

Destination  Address 

The  source  network  and  address  of  the  original  datagram's  data. 
ICMP  Fields: 

Type 

5 

Code 

0  s  Redirect  datagrams  for  the  Network. 

1  s  Redirect  datagrams  for  the  Host. 

2  «  Redirect  datagrams  for  the  Type  of  Service  and  Network. 

3  s  Redirect  datagrams  for  the  Type  of  Service  and  Host. 

Checksum 

The  checksum  is  the  16’bit  ones's  coaplement  of  the  one's 
cooplement  sum  of  the  ICMP  message  starting  with  the  IQ^  Type. 
For  cocBputing  the  checksum  .  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  in  the  future. 

Gateway  Internet  Address 

Address  of  the  gateway  to  which  traffic  for  the  network  specified 
in  the  internet  destination  network  field  of  the  original 
datagram's  data  should  be  sent. 
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Intemat  Header  *  64  bits  of  Data  Datagram 

The  internet  header  plus  the  first  64  bits  of  the  original 
datagram's  data.  This  data  is  used  by  the  host  to  match  the 
message  to  the  appropriate  process.  If  a  hi^lher  level  protocol 
uses  port  numbers,  they  are  assumed  to  be  in  the  first  64  data 
bits  of  the  original  datagram's  data. 

Description 

The  gateway  sends  a  redirect  message  to  a  host  in  the  following 
situation.  A  gateway.  Gl.  receives  an  internet  datagram  from  a 
host  on  a  network  to  which  the  gateway  is  attached.  The  gateway. 
Gl.  checks  its  routing  table  and  obtains  the  address  of  the  next 
gateway.  G2.  on  the  route  to  the  datagram's  internet  destination 
network.  X.  If  G2  and  the  host  identified  by  the  internet  source 
address  of  the  datagram  are  on  the  same  network,  a  redirect 
message  is  sent  to  the  host.  The  redirect  message  advises  the 
host  to  send  its  traffic  for  network  X  directly  to  gateway  G2  as 
this  is  a  shorter  path  to  the  destination.  The  gateway  forwards 
the  original  datagram's  data  to  its  internet  destination. 

For  datagrams  with  the  IP  source  route  options  and  the  gateway 
address  in  the  destination  address  field,  a  redirect  message  is 
not  sent  even  if  there  is  a  better  route  to  the  ultimate 
destination  than  the  next  address  in  the  source  route. 

Codes  0.  1.  2.  and  3  may  oe  received  from  a  gateway. 


[Page  13] 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  ONE 


1985 


RFC  792 


Septohber  1981 


Echo  or  Echo  Roply  Message 

0  12  3 

01234567890123456789012345678901 

4, -  4,-4, -4, -4 + -4- 

I  Typ<*  I  Coda  |  ChaelcBum  I 

4,_4,_4-4-4-4-.4-4-4-.4-4-4-4-4-4-.4-4-4'-4-‘4~4-4-4-4-  +  -4-4--4-  +  «4-4-  +  -4 

I  Identifier  |  Sequence  Number  1 

4-4-4-4-4.-4-4-4-4-4«4-4-4-4-4-4-4-4-4--4-4-4-4--4-4-4>-4--4-4-4-4-4-4- 

I  Data  . . . 

♦-♦-4-4-4- 


IP  Fields: 

Addresses 

•The  address  of  the  source  in  an  echo  message  will  be  the 
destination  of  the  echo  reply  message.  To  form  an  echo  reply 
message,  the  source  and  destination  addresses  are  slaply  reversed, 
the  type  code  changed  to  0.  and  the  checksum  reconputed. 

IP  Fields: 

Typa 

8  for  echo  message; 

0  for  echo  reply  message. 

Code 

0 

Checksum 

The  checksum  is  the  16*bit  ones*s  coaplement  of  the  one's 
complement  sum  of  the  XQf*  message  starting  with  the  ICMP  Type, 
For  computing  the  checksum  .  the  checksum  field  should  be  zero. 

If  the  total  length  is  odd.  the  received  data  Is  padded  with  one 
octet  of  zeros  for  computing  the  checksum.  This  checksum  may  be 
r^laced  in  the  future. 

Identifier 

If  code  »  0.  an  Identifier  to  aid  in  matching  echos  and  replies, 
may  be  zero. 

SequffKie  Number 
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If  coda  =  0,  a  saquence  number  to  aid.  In  matching  echos  and 
replies,  may  be  taro. 

Description 

The  data  received  in  the  echo  message  must  be  returned  in  the  echo 
reply  message. 

The  identifier  and  sequence  nuB^mr  may  be  used  by  the  echo  sender 
to  aid  in  matching  the  replies  with  the  echo  requests.  For 
exaople,  the  Identifier  mi^it  be  used  like  a  port  in  TCP  or  UDP  to 
identify  a  session,  and  the  sec;^ence  number  mi^t  be  incremented 
on  each  echo  req^uest  sent.  The  echoer  returns  these  same  values 
in  the  echo  reply. 


Code  0  may  be  received  from  a  gateway  or  a  host. 
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TlJMWtanp  or  TlMStanp  Roply  Message 

0  13  3 

01334567890123456789012345678901 
t  lypa  I  Coda  f  Chacksum  I 

I  Idantiflar  (  Saquanca  Nuabar  1 

i  Originata  TimastaB^  I 

i  Racaiva  Tiamtanp  I 

{  Tranaalt  Tlaaatanp  I 


IP  Flalda: 

Addraaaaa 

Tha  addraaa  of  tha  aourca  in  a  timaataiy  maanaga  will  ba  t>ia 
daatlnation  of  tha  tlaaataqp  raply  aessage.  To  fom  a  tiaeataap 
raply  aaaaaga.  tha  aourca  and  daatlnation  addraaaaa  ara  alaply 
ravaraad.  tha  typa  coda  changad  to  14,  and  tha  chackaua 
racooputad. 

XP  Flalda: 

Typa 

13  for  tlaMMta^p  maaaga, 

14  for  tlnaataap  raply  saaaaga. 

Coda 

0 

ChackauB 

Tha  chacd<aua  la  tha  16-bit  onaa*a  cooplaaant  of  tha  ona'a 
coaplaaant  aua  of  tha  ICMP  oMftaaaga  atartlng  with  tha  ICMP  Typa. 
For  coaputlng  tha  chackaua  ,  tha  chackaua  flald  should  ba  taro. 
Thla  chackaua  nay  ba  raplacad  In  tha  futura. 

Idantiflar 
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If  code  =0,  an  identifier  to  aid  in  matching  timestamp  and 
replies,  may  be  zero. 

Sequence  Number 

If  code  =  0,  a  sequence  number  to  aid  in  matching  timestamp  and 
replies,  may  be  zero. 

Description 

The  data  received  (a  timestaup)  in  the  message  is  returned  in  the 
reply  together  with  an  additional  timestamp.  The  timestamp  is  32 
bits  of  milliseconds  since  midnight  UT.  One  use  of  these 
timestamps  is  described  by  Mills  [5]  . 

The  Originate  Timestzjip  is  ttie  time  the  sender  last  touched  the 
message  before  sending  it,  the  Receive  Timestamp  is  the  time  the 
echoer  first  touched  it  on  receipt,  and  the  Transmit  Timestamp  is 
the  time  the  echoer  last  touched  the  message  on  sending  it. 

If  the  time  is  not  available  in  miliseconds  or  cannot  be  provided 
with  respect  to  xoidni^t  UT  then  any  time  can  be  inserted  in  a 
timestamp  provided  the  hi^  order  bit  of  the  timestamp  is  also  set 
to  indicate  this  non-standard  value. 

The  identifier  and  sequence  number  may  be  used  by  the  echo  sender 
to  aid  in  matching  the  replies  with  the  requests.  For  example, 
the  identifier  mi^t  be  used  like  a  port  in  TCP  or  UDP  to  Identify 
a  session,  and  the  sequence  number  might  le  incremented  on  each 
request  sent.  The  destination  returns  these  same  values  in  the 
reply. 

Code  0  may  be  received  from  a  gateway  or  a  host. 
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Information  Request  or  Information  Reply  Message 

0  12  3 

01234567890123456789012345678901 

j  Type  1  Code  |  Checksum  | 

)  Identifier  |  Sequence  Number  | 

IP  Fields: 

Addresses 

The  address  of  the  source  in  a  information  request  message  will  be 
the  destination  of  the  information  reply  message.  To  form  a 
information  reply  message^  the  sc.irce  and  destination  addresses 
are  simply  reversed,  the  type  coda  changed  to  16,  and  the  checksum 
recomputed. 

IP  Fields: 

Type 

15  for  information  request  message; 

16  for  Information  reply  message. 

Code 

0 

Checksum 

The  checksum  is  the  16 -bit  ones*s  complement  of  the  one's 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 

For  computing  the  checksum  ,  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  in  the  future. 

Identifier 

If  code  =  0,  an  identifier  to  aid  in  matching  request  and  replies, 
may  be  zero. 

Sequence  Number 

If  code  -  0,  a  sequence  number  to  aid  in  matching  request  and 
replies,  may  be  zero. 
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Summary  of  Message  Types 
0  Echo  Reply 

3  Destination  Unreachable 

4  Source  Quench 

5  Redirect 
8  Echo 

11  Time  Exceeded 

12  Parameter  Problem 

13  Timestamp 

14  Timestazflp  Reply 

15  Information  Request 

16  Information  R^ly 
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Description 

This  message  may  be  sent  with  the  source  network  in  the  IP  header 
source  and  destination  address  fields  zero  (which  means  “this** 
network) .  The  replying  IP  modul^*»  sliould  send  the  reply  with  the 
addresses  fully  Specified.  This  message  is  a  way  for  a  host  to 
find  out  the  number  of  the  network  it  is  on. 

The  identifier  and  sequence  nuznber  may  be  used  by  the  echo  sender 
to  aid  in  matching  the  replies  with  the  requests.  For  cucanple. 
the  identifier  mi^t  be  used  like  a  port  in  TCP  or  UDP  to  identify 
a  session «  and  the  sequence  number  might  be  incremented  on  each 
request  sent.  The  destination  returns  these  same  values  in  the 
reply. 

Code  0  may  be  received  from  a  gateway  or  a  host. 


[Page  19] 


1-597 


